Quit happening in wrong window

Targets macOS
1

I am using XOJO 2018 R1.1 and Mac High Sierra.
I have the menuitem FileQuit for the window in question Enabled = False.
I made a mistake and hit Command - Q in the debugger and it started the Quit process.
How can this happen?

2

The correct way to do it is to “return True” from the Cancel Close event of the window until you’re ready to let the window go.

3

Thanks. Consider that done. My confusion is I don’t have that menuitem in the Window So Command - Q is not valid.
It is in certain windows, like my main window, but not this one.
It might also be closing because I don’t have the main window open, but that should be re-opening since this one is closing.

But still I should be getting a beep for invalid selection.

4

Cmd-Q in the debugger first stops the debugging process which terminates your app, whatever state it’s in.

5

What Greg has suggested is probably the solution to your immediate problem, but this thread may be of interest to you in a discussion of FileQuit.
https://forum.xojo.com/41867-can-t-disable-filequit

6

I tried searching for quit Only and the post didn’t show. Grumble.
Thanks for verifying this is supposed to happen.
I read the post and it almost answers my problem.

I had removed appQuitting = false from this window’s cancelClose because it didn’t stop the Quit.
I also put it back in and it didn’t stop the Quit.
So, if appQuitting = False in the cancelClose doesn’t work, what would?

[quote]it would be much more polite to put a dialog in cancelclose telling the user that they must close the window first. If you do this

Return AppQuitting
7

You Return True in the cancelClose event to stop the window from closing or in the app.cancelClose event to stop the app from quitting. You must notify the user as to why you canceled

8

Figured out my bigger problem.
I have the main window that opens during the other window’s close event.
That is bad for Mac since Quit is already happening and will continue. Bad programming in retrospect.
Therefore, I add the FileQuit menu item to each other window with a dialogue.

Edit:
On further testing. The reason this is now happening is I now have only that second window open and had closed the main window.
In other words, in the main window, in the menuitem that opened the second window, I had self.close followed by otherWind.open
If remove that self.close then FileQuit doesn’t happen inappropriately,
but I need to add the menuHandler and the cancelClose handling in case that window is the only window open.

Further Edit:
The menuHandler for FileQuit is in each window’s since if it’s in App, it overrides any window’s menuHandler.
I also have code in EnableMenuItems

If WindowCount > 1 Then FileQuit.Enabled = False
9

Is there any reason for you to close the mainwindow? Would not self.hide work better? Then, I think, all those quit things, if they are really necessary, may start working properly, and the main window would be the last to get closed.

10

I had thought it would resolve its or my problem of updating its data and therefore it would un-hide. It caused more problems, so I went back to it being open.
The reason I chose to close it is its activate would cause it to reappear.
Thanks. I had forgotten about that problem.