Can't disable FileQuit

I have a window (Window2) with its own menubar. This menu bar has a FileQuit item indicated as a QuitMenuItem. When the user selects this menu item, my app crashes from this secondary window. I want to just disable this menu item, force the user to close this window first, then quit from the main screen. I have placed, at various attempts, the following items in the EnableMenuItems event of Window2:

FileQuit.Visible = False FileQuit.Enabled = False FileQuit.Text = "Close Window2 Screen"
None of these code lines has any effect whatsoever on the menuitem.

I found this forum post:
https://forum.xojo.com/36301-enable-disable-menuitems/0#p296794

but the items discussed in it don’t seem to have any effect on my app.
Any idea why I can’t seem to disable this menuitem?
Mac OS 10.12.5
Xojo 2017r1.1

Good. Do not disable the user’s ability to quit your app, they’ll just force quit it and then you could really get some screwed up data.

Find the reason Window2 is crashing when quit.

No. I’m not disabling the user’s ability to quit. They have ample ways to close this screen then can easily quit from the main screen. I just don’t want then to go directly to quit from this particular screen. The question here is "why do not of the lines related to FileQuit in the enablemenuitems event have any effect?

If window2 should not have a FileQuit… then create a duplicate menu without filequit for that window
I have an app with 1/2 dozen menu bars depending on the window that is active or other state of the app events

That was where I started. Window 2 DOES have it’s own separate menu. I tried removing FileQuit from the File Menu. A Quit item still appeared under the Application Menu as it would on any Mac. I added the FileQuit item in a failed attempt to get control of this menu item.

I will try later to recreate this in a simple app.

I the FileQuit Menu item set to be AutoEnable ?
And does you App class have a handler for that quit menu item ?

if so then what happens is you turn it off and the APP enables it because you have set things up basically saying the App CAN be quit from anywhere
Turn OFF autoenable and then make sure you set FileQuit.Enabled in the various EnableMenuItem events

The problem is, the user may decide they don’t really care (or maybe they think they are stuck), and force-quit from the dock or cmd-opt-esc menu. This could cause huge problems for your data, especially if quitting from Window2 is causing a hard crash anyway.

You’re using duct-tape and bubble gum to fix a hole in your boat.

I did a little test, even disabling AutoEnable like Norman suggested didn’t disable it.
I then deleted the item, and I still got an $APPNAME > Quit menu item.

It may be the OS sticking it there, and telling you that you can’t disable the user’s ability to quit.

But then this is what the CANCELCLOSE, CLOSE events and the AppQuitting flags are for

Good plan.

Might I also suggest adding some “system.debuglog currentMethodName” to the various events of the window, so that you can get an idea of where it might be crashing when selecting “Quit” from Window2.

I already did and indeed you cannot disable it as I suggested
Thats surprising but there’s a few things about quit menu items that are anomalous when you compare them to others
Like that you cannot change the shortcut at runtime like you can other menu items
I’ve added a note to this case <https://xojo.com/issue/46508>

But as an alternative IF having a Window2 open when you try to quit causes issues then use the cancel close event in window2 to return true which means Do not allow closing

Well certainly there are times when you don’t want a window to close. Think about when you quit an app and it says “do you want to save this document” and the buttons are Yes, No and Cancel. Yes saves the doc and continues to close the window. No does not save and continues to close the window. Cancel actually stops the window from closing. The app won’t actually quit until all of its windows close. The AppQuitting parameter lets you know if it’s the user clicking on the close widget or the Window.Close method being called vs the app actually quitting that’s causing the window to close. Returning True will prevent the window (and therefore the app) from quitting.

Yo me 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

Then the window won’t close unless the user specifically closed or did something to close it.

Thank you all for your input. Had I read this thread this morning I would have saved myself the time in creating a small project and confirming, as Norman has already done, that you can’t disable FileQuit. BTW - I know that a few versions back, I did disable the Quitting Menu option. This must be a new development. I will add my vote to Norman’s feedback case.
I can use a variation of Greg’s suggestions to work around the problem.
Thanks again for your suggestions.