cca@pur-phy (Charles C. Allen) (03/06/88)
I hope someone can point out my stupidity, or at least tell me that
the same thing doesn't happen with them. Otherwise, the limited
inheritance in HyperTalk is even more crippled.
* Create a new field and put some numbers separated by commas in
it. I had 5 items in a card field in an otherwise empty
stack.
* Now add the following script to the field:
on test
put item 2 of the target
end test
* Stare in dismay as nothing gets put in the message box when
you do a <<send "test" to card field 'blort'>> via the message
box.
Oddly, it works if you replace "item 2" with item 1. I didn't try
items 3, 4 or 5. No, changing the actual numbers doesn't make a
difference.
Where this really showed up was in something like the following:
on test
put item 1 of the target - item 2 of the target into snark
...
end test
The interpreter would come back with something like <<card field
"blort" is not appropriate for ->>. If you went to the script at that
point, the cursor would be right after the - sign.
What's up?
Charlie Allen cca@newton.physics.purdue.eduwinkler@Apple.COM (Dan Winkler) (03/08/88)
The target is a function that returns the name of the current target. If the target is a field and you want its contents, then refer to the value of the target: put the target -- puts the name of the current target put the value of the target -- puts the contents of the target
ns@CAT.CMU.EDU (Nicholas Spies) (03/09/88)
Is there any way to determine whether the contents of a field can be evaluated as a numeric expression (with "the value") without having it put up a dialog when the value can't be calculated? It would be nice to be able to let scripts deal with such cases if "the result" returned "Not a value". This might be handled by letting the HyperTalk programmer set system state variables to change default system actions within a handler, much as "set lockscreen to xx" works now. Giving commands properties that would reset to the default behavior between handlers would seem to offer a means to add new features at will while retaining compatability with current stacks. Begin able to say set reportError of value to false to turn off its default dialog response within a handler would allow much flexibility while retaining readable code. Imagine also being able to say set delimiter of word to ";" -- or anything else for parsing or set select of find to true to cause find to leave what it found in "the selection" rather than just highliting with a frame. Or how about set single of line to true to cause "the line" to return one line of text rather than text to the next carriage return. (This actually might be better as a settable property of text fields). Or how about set fullLine of sort to true to cause sort to base its action on a full line of text rather than obligating the programmer to concatenate strings to get this effect. The alternative to this or some comparable means of extending HyperTalk is the chaos of having to write or depend on home-built XCMDs and XFNCs of unknown reliability. (Speaking of this, does Apple have any plans for creating a library of XCMDs and XFNCs; it would seem to be at least as important as the registration of font names...) -- Nicholas Spies ns@cat.cmu.edu.arpa Center for Design of Educational Computing Carnegie Mellon University
john@felix.UUCP (John Gilbert) (03/09/88)
In article <1011@pur-phy> cca@pur-phy (Charles C. Allen) writes: >I hope someone can point out my stupidity, or at least tell me that >the same thing doesn't happen with them. Otherwise, the limited >inheritance in HyperTalk is even more crippled. > > * Create a new field and put some numbers separated by commas in > it. I had 5 items in a card field in an otherwise empty > stack. > > * Now add the following script to the field: > > on test > put item 2 of the target > end test > > * Stare in dismay as nothing gets put in the message box when > you do a <<send "test" to card field 'blort'>> via the message > box. The problem here is that the expression "the target" evaluates to a string containing the name of the target, and the binding is such that it does not further evaluate the entire command using the name of the target. In other words, whay you are really executing here is: put item 2 of "card field blort" where "card field blort" is the actual data sent to the item function. Since there are no commas in the string, you get nuttin'. This does seem inconsistent when you consider that: get the loc of the target -- is equivalent to: get the loc of card field "blort" whereas... put item 2 of the target -- is NOT equivalent to: put item 2 of card field "blort" This seems to indicate that the expression "the target" is not to be consisered a MACRO, but an expression which is evaluated once. In your field, try: on test get the target put it end test It will show the name of the field. For my use, it seems like "the target" would have been more useful to evaluate to the contents, and require applying the function "get the name of the target" when that is what I want. However, "the target" may also refer to buttons, which do not contain values, just properties. Anyone know if there is a reasonable way to use "the target" in the case of a field to get the contents, other than using the "do" command on a string I build? John G. -- John Gilbert !trwrb!felix!john
john@felix.UUCP (John Gilbert) (03/10/88)
In article <24353@felix.UUCP> john@felix.UUCP I wrote: > >just properties. Anyone know if there is a reasonable way to use "the target" >in the case of a field to get the contents, other than using the "do" command >on a string I build? I have since found the 'value' function which seems to do just what is needed. Thanks anyway! Now for a more technical question. I am writing an XCMD to copy resources from one file (stack) to another, so that I can release a stack with a bunch of 'snd 's in it, and have it install them where you tell it. I know there is already one floating around, but this is mainly a learning exercise. Well, it basically works, except when the target file does not yet have a resource fork. I am looking for this, and basically do the following: if ( (target = OpenResFile( targetFile )) == -1 ) { CreateResFile( targetFile ); if ( ResError() != noErr ) { return; } else if ( target = OpenResFile( targetFile ) == -1 ) { return; } } Well, the XCMD continues to function, but near completion, or immidiately after returning to HyperCard, things go haywire. Either the screen locks up (usually), or pulling down menus to look at stack info causes HyperCard to unexpectedly quit. On occaision, my system will not reboot from my hard disk, it just keeps trying, but when it get's to the desktop it instantly returns to happy-Mac and tries again. Replacing the system file fixes it. In cases where the resource fork already exists it seems to work flawlessly time after time. Is there something I am missing about creating the resource fork of the file? I do later read the file looking for a conflicting resource name before ever putting anything in it. Tonight I am going to try being a bit smarter about that. Does this suggest anything to anyone? I have very early versions of Inside Mac. Thanks for any help.... John Gilbert -- John Gilbert !trwrb!felix!john
edmoy@violet.berkeley.edu (03/11/88)
In article <24416@felix.UUCP> john@felix.UUCP (John Gilbert) writes: >Well, it basically works, except when the target file does not yet have >a resource fork. > >I am looking for this, and basically do the following: > > if ( (target = OpenResFile( targetFile )) == -1 ) > { CreateResFile( targetFile ); > if ( ResError() != noErr ) > { > return; > } > else if ( target = OpenResFile( targetFile ) == -1 ) > { > return; > } > } > If this is exactly the code you use, then the problem is in: else if ( target = OpenResFile( targetFile ) == -1 ) You forgot the extra pair of parenthesis, as in else if ((target = OpenResFile( targetFile )) == -1 ) What you were doing is calling OpenResFile() and testing if it was -1. If it was, target was set to 1 (true) and your routine started to do its thing on what every resource file 1 was (maybe the System file). Although I would have expected that OpenresFile() to return a positive number, which doesn't match -1, so target becomes 0 and your routine returns. Edward Moy Workstation Software Support Group University of California Berkeley, CA 94720 edmoy@violet.Berkeley.EDU ucbvax!violet!edmoy