Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uwm.edu!gem.mps.ohio-state.edu!ginosko!aplcen!haven!mimsy!brillig.umd.edu!spector
From: spector@brillig.umd.edu (Lee Spector)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: Message Window: probs w/global variables
Summary: Thanks, but the problem remains unsolved.
Message-ID: <19527@mimsy.UUCP>
Date: 12 Sep 89 03:53:23 GMT
References: <19503@mimsy.UUCP> <90741@ti-csl.csc.ti.com>
Sender: nobody@mimsy.UUCP
Reply-To: spector@brillig.umd.edu.UUCP (Lee Spector)
Organization: U of Maryland, Dept. of Computer Science,
Lines: 49

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)