fkpj@vax5.CIT.CORNELL.EDU (01/27/89)
Well, I have gotten only one response to my question saying basicly, "I noticed this to, let me know what you find out" Let me try it again. When you have a stack with multiple backrounds it appears to be impossible to limit a find to a particular field on a particular backround. HC (1.2.1) appears to convert what ever specifier you give to the NUMBER of the backround field and then look for that number on all backrounds. Have I assessed the situation correctly? If so, I find this to be extremely undesirable behaviour. When I say I want to search field "tom" of backround "jim" I don't want HC deciding that "tom" is number 15 and go looking for number 15 on all backrounds in my stack. The only way around appears to be write my own loop to access just the fields I want and check them for the string I'm looking for. Truely a pain. Also it would appear from page 121 of the hypercard user's guide that find can be restricted to a card field yet I have been told that the hypertalk document (I have not seen it) says that this is not possible. A small documentation inconsistancy that it might be nice to clean up :-) Todd Olson olson@helios.tn.cornell.edu
dan@Apple.COM (Dan Allen) (01/28/89)
In article <17813@vax5.CIT.CORNELL.EDU> olson@helios.tn.cornell.edu writes: >When you have a stack with multiple backrounds it appears to be >impossible to limit a find to a particular field on a particular backround. > >HC (1.2.1) appears to convert what ever specifier you give to >the NUMBER of the backround field >and then look for that number on all backrounds. Todd, here is your official (sad but true) answer: You are RIGHT. At the start of a find command HyperCard converts a field name to a field number, based on the current background and card. That number is then used throughout the stack. It is true that this behavior makes things problematic if field "foo" on background one is field 1 and field "foo" on background two is field 2. However, doing it otherwise would make find quite a bit slower, as find would have to re-evaluate this name->number mapping on each card. A LOT SLOWER. We (Bill) decided that it was best to do it this way and so what we should do is document this behavior better so that stack designers can number their fields in a consistent order. Thanks for the input. Dan Allen Apple Computer