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