Michael Binder wrote:
Hi Jacqueline,
You wrote:
Ah, I see. Okay. Then you want:
put the id of this card of stack "myApp" into thisCd
Now "thisCd" contains the id of the card. Or you could ask for the short
name of the card if that's easier and your cards are all named.
I don't think that works. That is (more or less) what I originally
tried. From my original post:
on shutdownrequest -- this does not work as expected
if the short name of this cd is "dataEntry1" then
validateData1
else if the short name of this cd is "dataEntry2" then
validateData2
end if
offerChanceToSave
end shutdownrequest
Your way is a little different, the handler just asks for "this card".
When there is no stack reference, the engine will assume you mean the
current defaultstack and look there for the card. (Remember, the stack
you are looking at is not necessarily the defaultstack.) The
defaultstack is the one that will receive all messages first, and it
changes depending on various events. In your app, some action (in one
case, the "answer" command) is triggering another stack to become the
defaultstack.
A sidenote: The answer dialog is not built into the engine the way it is
in HyperCard. The dialog is just a regular stack, and receives messages
like any other.
Note that the defaultstack doesn't matter at all if you provide a full
stack reference. Adding "of stack <mystack>" to a card reference forces
the engine to look in the stack you designate. All your original script
needs is a little tweak:
if the short name of this cd of stack "myApp" is "dataEntry1" then...
What I have found is that "this stack" doesn't evaluate
to the stack that the user is looking at.
Right. It evaluates to the current defaultstack.
Also "this card"
doesn't evaluate to the name or the ID of the card that the
user is looking at.
Same deal; it evaluates to the current card of the defaultstack.
(How could the engine know what "this
card" is if it doesn't even know what "this stack" is?)
The engine knows. Back in HyperCard, only one stack could be open at a
time. Even after multiple windows were introduced, at the engine level
there was really only one stack. Any stacks that weren't topmost were
actually gone; only their image was left on screen. Because there was
only one, "this stack" was always the one you were looking at.
In Revolution you can have many real stacks open at a time, and any of
them can be "this stack" whether they are drawn at the front or not, or
even if they are invisible. It's possible to set the defaultstack in a
script, so that you can work with another stack as though it were "this
stack" while leaving the original stack at the front. This is handy for
doing all kinds of things in the background, while to the user the front
stack never appears to change.
The engine tracks stacks several ways, two of which are "topstack" and
"defaultstack". Sometimes they are the same thing, and often the stack
that is visible and in front of all the others is both. But not always.
One extensive use of "defaultstack" is in the message box (which is also
just another scripted stack.) When you put a command into the message
box, its script sets the defaultstack before executing your command.
That allows the commands you type to go to your stack instead of being
sent to the message box stack.
I know that there are plenty of projects out there that
need to trap the Quit command and do various things. How
do others manage to figure out where the user was when the
Quit command was issued?
The best way is the way you've done it -- ask the engine about the stack
and branch the script behavior based on what you get back. All your
original handler needs is a stack reference.
It might all come clear if you take a look at the dictionary entries for
"topstack" and "defaultstack".
--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
