Quitting standalone, is this a bug?

[Michael Binder]

Hi Jacqueline,
Nice work investigating this bug!  Now we have three types of
work-arounds, my "the recentcards" approach, your "explicit
stack reference" approach, and your "set the defaultstack"
approach. I have tested the latter in myBigComplexApp and it
seems to work. I most prefer your "defaultstack" approach.
Thank you so much!

Now, would you go one step further and agree that this bug
is very serious because it causes data loss?  Let me explain...

Jacqueline wrote:
 > If a second answer dialog is executed immediately after
 > the first, subsequent lines of code in my handler do not
 > execute. What's odd, however, is that the "pass
 > shutdownrequest" line at the very end of the handler *does*
 > run -- but that seems to be the only thing.

Upon Quitting myBigComplexApp, the user is offered a chance
to Save, Do Not Save, or Cancel.  If the user "Saves",
the only part of my handler that executes correctly is
the "pass shutdown request".  Thus the app quits without
saving the data.

One other thing... I do not feel that this bug has been
fully characterized.  In the simple example that I first
posted (and that Jacqueline tested), the bug crops up
only when the Quit dialog is cancelled and then called up
again.  In myBigComplexApp the bug occurs on the *FIRST*
Quit dialog.  That, by the way, is how I discovered this
bug (data loss upon quitting).   I doubt that I would
have discovered this bug if I had to Quit, Cancel, and Quit
again to elicit it.  I don't (yet) know why it behaves
differently in myBigComplexApp.  Until I do learn more
about it, I cannot be 100% confident that the work-arounds
will always work (but I am 99% confident in Jacqueline's
diagnosis and work-around.

And one last thought for today... upon rereading this
thread and rerereading the documentation I have an
hypothesis to try and test...

 From the dictionary: The topStack is the frontmost stack
with the lowest mode.

 From the documentation: A stack that is closed, but loaded
into memory has a mode property of Zero.

If the rev engine closes a dialog stack but fails to
remove it from memory, its mode would be zero.  I don't
see how it could also be frontmost if it is closed, but the
behavior of the bug (usually occurring on the second dialog),
suggests that the dialog must be loaded into memory once
before it can cause problems.  Perhaps when the dialog
is called a second time the engine makes it frontmost
*before* the engine changes its mode from 0 to 5.  In that
instant the dialog could become the topstack and the defaultstack.

--Michael Binder