Why does Close fail?

I create a subwindow that is a modal window.

I have a MenuItem called FileClose. I also have FileQuit. It also has a shortcut ?w.
Only in the subwindow, FileClose is enabled by enablemenuitems.
Only in the subwindow does FileClose have code >> Self.Close.

Why doesn’t the subwindow’s enablemenuitems fire?
Why isn’t FileClose enabled in the subwindow as in dark for the text (not grey)?
Why doesn’t the menuitem fire?

Close Window.xml

If I had to guess, the logic would be that on Mac a palette window is not a full-on document window. They are accessories to the main document window.

This paradigm is for one menubar across the whole app, so these accessory windows should not change the menu items, or handle them.

Sorry. I was hoping for a way to stop the parent window from closing until the child was closed.
It’s not possible. Either everything closes or it doesn’t.
What I want is an easy, effective and simple way of managing sub-windows.
I haven’t found all of the pieces for managing everything from pointers and some sort of table, etc, etc.

Use Sheets to attach a window to a parent window. They are modal like you’re trying to achieve.
It won’t work like a tool window though.

It’ll do for now.

You could try this method (assuming that you are on the macOS platform only) in order to create a child window that is always on top and also moves with the parent window.

https://forum.xojo.com/43480-keep-window-at-front-macos/p1#p353127

I’m not sure if you will run into the same issues with the menu items, but it’s worth a try.

It does mostly what it’s supposed to do.
With one exception.
I HAD 2 ways to close the window. ctrl-w or press the close button.
Now if I press the close button (code inside Self.close) the controls on the window disappear and the window itself remains.
It goes thru the whole routines, but the window without controls remains.

That seems very strange.

You might want to try turning Implicit Instance off for that window.
That may or may not solve the issue, but it’s worth a shot.

Or maybe un-pairing the windows before closing will help?

soft declare sub removeChildWindow lib "Cocoa" selector "removeChildWindow:" (parentWindow As Ptr, childWindow As Ptr) removeChildWindow(Ptr(Self.Handle), Ptr(Window2.Handle))

If you could post and example project that exhibits this behavior, we might be able to work out what’s happening.

I agree. Tested on Mac without implicit
Changing Implicit didn’t work.
Here’s the project with that in it.
Close window xml

Ok, I see what’s going on here.

First thing is that you need to select which menu bar to use for your child window (in this case it’s called MainMenuBar).
The EnableMenuItems event doesn’t know what menu bar to address if you haven’t selected which one to use.

After that you have a choice to make:
If you want the window be always on top, but floating (like a palette), then you can use the declare that I linked, but the child window can’t be a Sheet Window. If you change it to a Document, then it will work as expected.

If you want to use the Sheet Window, that’s also a fine approach, but you can’t use that with the declare as it is already a child of the main window.

I hope that helps!

Thanks. Tested on PC. I had the menu turned for the above problem. I’ve been trying to solve it for days and may have sabotaged my efforts.
Sabotage is so easy.
I’ll test it my Mac later.