Sorry for asking this again. I am unclear about what is going on and am not sure what is expected behavior.
This is only a Mac (versus Windows) problem.
This is also document frame versus Other frames like floating frame problem.
For comparison of expectations, from Apples Mail open a email in its own window. If you go to close the window, then that email window gets closed and not the Mail app first. This does not happen in this instance.
I have a child window (Ch) that is opened by the parent window (Pa). This Ch window, regardless of frame type appears On Top.
Both menubars are called out in the Layout and in their event Open.
This Ch window has its own menubar (its also used for all small windows):
Self.MenuBar = MenuBarSm
If Ch is Not a Document window, it is also in this instance NOT window(0), even though it is on top.
This Pa window has the All menubar.
Self.MenuBar = MenuBarAll
The basic problem: If Ch is Not a document window, it should be window(0) but it is window(1)
If the child window Ch is a document (frame property) window then the menubar MenuBarSm gets activated and it is also window(0). If not a document frame then any menu operations are on the parent window Pa and not Ch (Pa is in this case window(0)). This becomes a problem if I attempt to close the top window Ch via menukeys Command-W. Ch does not close, even though it is the top window. Pa closes instead.
Also, whether I have Ch.showmodal or just Ch.show and it is not a document window there is no effect on its rude closing behavior.
In otherwords, for Ch being a non-document window and being On Top, all menu actions are from the Pa window including close. If I try via a menuitem to save what is in Ch, and it is a floating window, I save Pa, and not Ch.
What menu appearance is normal behavior when a Mac sub window is not a document window?
Its own menu?
The parents menu?
What could be going wrong that Ch is Not Window(0)?
Don’t know why you’re seeing issues with this, but a simple solution is to implement WindowClose menu handlers on windows instead of on App and closing Window(0)
Much easier to determine if a window can be closed this way. For instance you wouldn’t want the user to be able to close a modal sheet or progress window. Now you simply just don’t implement the WindowClose handler on them, instead of checking the window type in the MenuHandler on App.
I actually do have separate handlers for most operations. I double-checked via the debugger before posting, Pa’s close handler processes and finishes. Then I do the menu item again and Ch closes.
Yes.
I am away from my computer, but yes and it does not fire if other than a document.
This will hopefully not muddy it. Following the close is something like window(0).show. That makes sure the Pa window shows and not some other one.
Dont get hung up on what YOU think Window(0) should contain.
Dont do window(0).show
In your app, create a property
PA as parentwindowtype
when you open the parent,
app.PA = new Parentwindowtype
Now, open as many child windows as you want.
In their Windowclose, put self.close
But you do not automatically need to bring Parent to the front: there many be other child windows. (Should they be modal?)
If the window count goes down to 1, and you are concerned that your parent window might not be visible, you can call
As I wrote earlier, if you re-create that in an new project, this is not the result on both macOS and Windows. The child window regardless of being a document or a floating window will be Window(0) and the parent window will be Window(1).
As I wrote earlier, this is the correct behavior. A floating window cannot have its own menubar.
Thank you very much Eli O. That I can understand. It tells me I have many Menuitem.enabled = false to add.
I changed the menubar to All, but it wasn’t the cause of it not being window(0). Grumble. That would have been easy.
Do you know any reason why the child window would not be window(0)?
Edit: I looked at the example in Desktop/Windows/ModalWindowExample and it behaves correctly.
I tried adding
Dim chh as New Ch
chh.showmodal
but that didn’t change anything.
Nor did changing it to implicitinstance = false.
I already maintain an array list of open windows and could easily create pointer reference list to these Ch windows, but I don’t think that will solve my problem. It’ll only be a workaround for a bug.
There is also a nice example in the examples projects for Desktop/Menus/WindowMenu
While reading XDEV, the suggestion was made to look at Feedback cases.
Can anyone tell me about this case? It’s still unresolved. It sounds very similar.
For anyone who wants to look at what I trying to explain - child not being window(0) - can view this project. ChildWindow.Xojo XML.
Sorry. But I can’t figure how to share it with anyone.
If you open the window and click the close button on the child window,
then in the Debugger open Globals and then windows, you will see ChildWindow as not being window(0).
If this is a XOJO mac bug please tell me.
If not then I have these problems.
If you can explain how to manage this from Window1 that would be good. Especially with implicitInstance off. Window.name is the easy part. They would all be unique.
FileQuit works on a modal window and I would need to disable that.
Other questions.
4. #App.kFileQuit This line showed up in FileQuit when I added the menuitem but I can find no mention of it. Where can I find documentation on it.
5. When I added FileClose to the child window, it also added to the Window1 and I couldn’t delete it. I had to change its name to Burp.
Note for 2: This code might work but I don’t understand how to implement it here.
[quote]Dont get hung up on what YOU think Window(0) should contain.
Dont do window(0).show
In your app, create a property
PA as parentwindowtype
when you open the parent,
app.PA = new Parentwindowtype
Now, open as many child windows as you want.
In their Windowclose, put self.close
But you do not automatically need to bring Parent to the front: there many be other child windows. (Should they be modal?)
If the window count goes down to 1, and you are concerned that your parent window might not be visible, you can call