Quitting standalone, is this a bug?

[J. Landman Gay]

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         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com