Quitting standalone, is this a bug?

[J. Landman Gay]

Michael Binder wrote:
> 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!

No problem. I like that approach best too.

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

I've entered the bug into the Quality Control Center, but marked it as 
"minor". There are specific requirements listed for rating a bug's 
status, and if there is a work-around available (and we have three) then 
that's the correct rating.

If you would like to add your comments, you can do it here:

<http://quality.runrev.com/qacenter/show_bug.cgi?id=4994>

> 
> 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.

I'm pretty confident about it, I think you can implement the change 
without worry. I agree that my bug report, based on my tests, may not 
represent the full extent of the problem but I think it's probably 
enough for the engineers to see what's going on and fix it. If you have 
other examples though, it would be great if you could add them to the 
report.

> 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.

Maybe, who knows what's going on in the engine. What I suspect is that 
the engine is losing track of the defaultstack, and it may be that the 
report you got about "this" stack was based on an earlier value which is 
no longer valid, or else the engine is just reporting a spurious result.

By the way, I was talking to Richard Gaskin about this and he noted that 
he'd seen a similar problem in his stacks with the answer dialog (not on 
quitting, just in general use.) It just cropped up recently; previously 
the same scripts worked fine. He thinks the bug was introduced when RR 
fixed a separate window layering problem. That makes sense and fits the 
data, including your observation that sometimes the problem occurs on 
the first iteration of the dialog.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com