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 | [EMAIL PROTECTED]
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
