The case was verified, then closed as not reproducible in future versions of RS.
The window appears, I click a button in the window to dismiss it, and the application does not execute any code after that. WHen I pause the debugger, it is stuck on the line of code that should return the selected button (b) from the dialog (d) shown within the window (w):
b = d.ShowModalWithin(w)
The debugger stack and properties panes shows that the dialog still exists after it has been dismissed.
I thought that’s the way it used to work as well, but when I downloaded the first revision of 2015r2 (r2.1 I assume it was) the IDE told me I could not compile my apps because I did not have a license for it. My update plan had expired 1 week previous to the release. I could run it the debugger, but I immediately erased it from my machine because the newest version always becomes the default app launched by all my code files.
If you are licensed for a major version (rM), then you are licensed for all its bug-release versions too (rMb), so your license will allow you to use fully any 2015r2X but won’t let you use r3 when that’s eventually released.
If you’re having trouble, contact customer service, but I just confirmed with @Dana Brown that this is true.
At any rate, if the bug’s been fixed in r24, that’s your only path.
Well, looking at the updates now on Xojo, it was indeed 2015r2.1 that I tried to install and it told me I couldn’t use it. Xojo changed the way they handle this. I had updates through the first week of April and r2.1 was released April 22nd (two weeks after my update plan expired, not 1 week as I said above). I don’t have a license for anything past the first week of April 2015.
The dialog closes through user interaction. A button is pressed, and the dialog closes. The button the user clicked is supposed to be returned, and code execution is supposed to continue.
b = d.ShowModalWithin(w)
What happens is, the dialog appears, the user clicks a button, the window disappears, and then the app does not resume executing code. Pausing the debugger shows the line above highlighted, and the info panes show that the dialog (d) still exists and the button (b) is Nil. The button has been clicked, the window has disappeared for the user, but the main thread is still waiting for something to happen.
[code]
dim d as new MessageDialog
dim b as MessageDialogButton
d.icon = MessageDialog.GraphicNote
d.ActionButton.Caption = “Save”
d.CancelButton.Visible = True
d.CancelButton.Caption = “Cancel”
d.AlternateActionButton.Visible = True
d.AlternateActionButton.Caption = “Don’t Save”
d.Message = heading
d.Explanation = msg
b = d.ShowModalWithin(self) '<-- debugger stalls here after user dismisses the dialog …
’ stalls above only when more than 1 doc window is open
’ changing “self” to “me” doesn’t do anything.
’ using b = d.ShowModal instead works as expected
’ this is all exactly as described in https://xojo.com/issue/20701
The Termination Process in GUI Applications
This is the order in which events are called when a GUI application initiates a termination process, i.e. when it quits:
Application.CancelClose is called first. If, for any reason, you want to stop the termination process or interact with the user (use a modal window in such a case) to confirm, you should do it in this event. If you return true, the termination process will be stopped immediately.
Window.CancelClose is then called for each Window, one after the other. If any Window.CancelClose returns true, the termination process will be stopped.
The code above is in the CancelClose event of the Window. I will try moving it into a loop for each window in the App.CancelClose event since that takes place first and see if there is any difference.
The code has to be in the Window CancelClose event because user doesn’t always select “Quit”. They might just want to close a window. So I wrote code in both places to handle either situation.
Result: it doesn’t matter from where or in what order this code is called. If more than one document window is open, the code execution gets stuck on this line: