spector@brillig.umd.edu (Lee Spector) (09/10/89)
Since I don't like the fact that the message box contains only one line (causing old commands and results to be lost) I've been trying to hack together a "message window" that'll act like windows in other interpreted languages. (Sort of like a "listener" window in Lisp). The basics are easy: grab the last line of the window, evaluate it somehow (by calling "do", moving it to the message box, or some other trick), put the result into the next line of the window, and scroll appropriately. By making this into a "returnInField" handler for the field you can get reasonable results. HOWEVER, things get considerably worse when you try to set global variables from your window. For example, try "put 5 into j". Following this with "j <return>" gets you a "Can't understand j" message BECAUSE j WAS NOT SET GLOBALLY. This is true whether you evaluate with "do" or by moving the relevant line to the message box and sending EnterKey. Now I don't know what rules HyperCard uses for variable scoping (is this written up anywhere? Is it even consistent?) but by playing around I've found that I CAN set the variable globally by creating, on the fly, a script for a hidden field that looks like this: on kludge global j put 5 into j end kludge Then I can send a "kludge" message to the hidden field to set the variable globally. HOWEVER, I must also do this sort of thing to REFER to j; that is, in order to beable to type "j" and get 5 I must stuff it into a script with the appropriate "global" statement. NOW THIS GETS REALLY MESSY, because the script has to have a different form depending on whether the given line is a command (like put...) or an expression (like 2 + 2). Further, if I want to allow for arbitrary references to global variables then I'll have to do something very complicated (?). In short, I'd have to rewrite the hypertalk language parser and implement a copy of its run-time symbol table as well! I conclude that there must be (BETTER BE) a better way. How can I evaluate a string JUST AS THOUGH I HAD TYPED IT TO THE MESSAGE BOX AND TYPED RETURN? It seems like you could just script this, but as far as I can tell the fact that it's scripted changes the scope of the variables in the string. If anyone has any insights, knows of a write-up of HyperTalk's scoping rules, or knows of an already-written message window package, please let me know. Thanks! -Lee (spector@brillig.umd.edu)
martin@m2.csc.ti.com (Steven Martin) (09/11/89)
In article <19503@mimsy.UUCP> spector@brillig.umd.edu.UUCP (Lee Spector) writes: >I conclude that there must be (BETTER BE) a better way. How can I evaluate >a string JUST AS THOUGH I HAD TYPED IT TO THE MESSAGE BOX AND TYPED RETURN? >It seems like you could just script this, but as far as I can tell the fact >that it's scripted changes the scope of the variables in the string. How about putting the string into the message box and then doing a "type return". on mydo string put string type return end mydo Good luck! Steve Martin USENET: {ctvax,im4u,texsun,rice}!ti-csl!martin ARPANET: SMARTIN@CSC.TI.COM COMPUSERVE: 72727,1471 GENIE: S.MARTIN8 PHONE: (214)-995-0387, 404-1061 I'll have four whole fried chickens and a Coke. -Jake Blues
spector@brillig.umd.edu (Lee Spector) (09/12/89)
Thanks to those who have taken the time to to think about this problem. Some of the advice is useful, but the problem has not been solved. martin@m2.csc.ti.com (Steven Martin) writes: >How about putting the string into the message box and then doing a >"type return". > >on mydo string > put string > type return >end mydo Unfortunately this does not work, because of the scoping problem I mentioned. Try it with the string "put 35 into foo" and then try to get the value of foo - only a local variable was set. You can verify that the string WAS evaluated and that the LOCAL variable WAS set by adding "put foo" after "type return". But since the global was not set we have not solved the problem. LAWRENCE@S47.Prime.COM writes: >Just require that the user explicitly type the 'global j' statement - >recognize it, and save the 'j' in a hidden field. Then build your >handler each time by prepending a global statement with all the >variables declared so far. This is better but there are still several problems: 1) I don't WANT to require this of the user! The idea of a message window is to make interactive experimentation EASIER. Having to declare all temporary variables would be a pain and would defeat the purpose. 2) There's still the problem of how to build the REST of the handler. Yes you could add lots of "global" statements to take care of variable references, but you'll need to have the last line of the handler to be just what the user typed if it was a command, or "return <what the user typed>" if it was an expression. (In the message box you can type an expression or a command, but you get an error in a handler if a line is either just an expression or "return <command>"). How do you tell a command from an expression? Is Fizbin (2 + 2) a function call or a command?? It could be either... --- So I'm still looking for a trick that will allow me to create a message window to replace the annoying 1 line message box. I'm wondering if there's an XCMD callback that will evaluate the message box in the global context (even if it's called from a script). Anybody know? Thanks again, -Lee (spector@brillig.umd.edu)
spector@brillig.umd.edu (Lee Spector) (09/12/89)
In article <19527@mimsy.UUCP> I (Lee Spector) write: >So I'm still looking for a trick that will allow me to create a message >window to replace the annoying 1 line message box. My terminology was bad here - I really meant "message field", not "message window". I want a scrolling field into which the user can type commands and get results. A message *window* would be even nicer, of course, but this is obviously more difficult and not really necessary for my purposes. Thanks -Lee (spector@brillig.umd.edu)