jpa@colman.newcastle.ac.uk (John Aspden) (11/11/89)
I know this has been discussed on the net before, but I didn't pay much attention the first time through. Since then, I've done quite a bit of work in HyperCard, and the problem was brought to my attention by a colleague who had stumbled across it when he was having problems trying to get his stack to work correctly. The problem is the one of restricting a FIND to a specified background field - as confirmed earler in this group by Dan Allen, and acknowledged in Apple's Q&A stack. To quote from the latter: >When Hypercard executes "find something in field aField" it >immediately converts the field name to a field number (not a field >ID). Suppose "aField" is background field 5. Hypercard starts with >the current card and proceeds forward through the stack, looking for >"something" in field 5. It doesn't check the name when it crosses >backgrounds Q it will continue looking at field 5 in each background. >If it encounters a background that doesn't have a field 5, it will >start looking at all fields. This behaviour has two consequences. First, if a field "aField" on one background is number 5 and on another bg is number 4, if the find was executed with the current card having bg 5, 'find "blah" in field "afield"' will never find text in field "aField" on bg4. One could argue that having background fields with the same name on different backgrounds is a dangerous practice, especially if they have different numbers, but the behaviour is unexpected. The more serious (IMHO) consequence is that a completely different field will be searched on a different background, and a false success may be achieved. If I rely on success to carry out further actions with the assumption that I've really found something where I expect it, I can do horrible damage. So what's the official solution? ... >There are two workarounds to this: > > - Put empty, invisible fields in backgrounds you don't want to search, > and make them the same number (use bring closer/send farther) as > the field you will be searching. Because the fields are empty, >nothing will be found in them. > > - Change your "find" script to check the background and field names >when it finds whatever you are looking for. The first of these is simply a nuisance. The second is ridiculous - let's take this line of reasoning to its absurd conclusion. Find works this way for reasons of speed. So how about: - "In release 17.01 of HyperCard we have improved the already impressive - search speed even further. From now on, the search will not actually - be carried out, but a random number will be generated and used to - index into an arbitrary position in the text of the stack. Since this - will not always find the actual text you are looking for, the - workaround is to change your "find" script to check the actual found - text when it "finds" whatever you are looking for." In my opinion, the present behaviour is worse than useless. Anyone agree or disagree? ------------------------------------------------------------------------------ John Aspden ARPA : jpa@newcastle.ac.uk Phone: +44 91 222 8069 UUCP : ...!ukc!newcastle.ac.uk!jpa ------------------------------------------------------------------------------- "A satisfied customer - we should have him stuffed!" ... Basil Fawlty