I have an app that has a main list window and can open multiple windows from it. To manage the various windows, I created a floating window that groups related windows together logically and lets user navigate to any one of the windows or close a group all at once. This works flawlessly on the Mac.
It works well on Windows too as long as the floating window is opened from the list window’s menu. If it’s opened through the menu of one of the other windows, that window seems to “own” the floating window. Clicking on the floating window bring the other window to the front too. Worse, using the “close” widget on the floating window to close the other window will crash the app.
I hope all of this makes sense. Is there a solution?
My immediate solution is a build script that changes the Frame to Document before a Windows build, and to Floating before a Mac build, but I hope there’s a better answer than that.
I have exactly the same problem. One mainwindow with list where You can open multiple listitems in datawindow. Also one configwindow (floating) that is opened from mainwindow but also accessible from datawindows.
When accessed from datawindow mainwindow also comes to front on windows platform.
[quote=169982:@Kem Tekinay]I have an app that has a main list window and can open multiple windows from it. To manage the various windows, I created a floating window that groups related windows together logically and lets user navigate to any one of the windows or close a group all at once. This works flawlessly on the Mac.
It works well on Windows too as long as the floating window is opened from the list window’s menu. If it’s opened through the menu of one of the other windows, that window seems to “own” the floating window. Clicking on the floating window bring the other window to the front too. Worse, using the “close” widget on the floating window to close the other window will crash the app.
I hope all of this makes sense. Is there a solution?[/quote]
As far as I understand the Window class in Windows, it does make sense. Windows are hierarchic. Parent and child. So if you open a window from another one, it is child.
The solution for what you describe would be to instantiate the floating window in App. And have a method in app that is called from the windows to instantiate them. So they will be owned by App, and not by anyone of them.
The menu handler that opens that is in the App menu handlers, so App is already handling it. Or did you mean something else?
Even if not, you gave me another idea. I could open the window on Open, then hide it if needed. From then on, in Windows only, the Window could hide itself instead of closing in CancelClose.
This is a potential workaround, of course, not what I would consider a “fix”. I’ll report back.
[quote=170070:@Kem Tekinay]The menu handler that opens that is in the App menu handlers, so App is already handling it. Or did you mean something else?
The notion of windows owning others is indeed there.
You mention opening a window from another window seems to make it dependant on that one, which would tend to correspond to that. Now the way it works through a handler in App is a mystery to me.
I wonder if opening the window not in a regular handler but in a timer in App would not sever the link.
At any rate, since the floating window will be opening other windows, and I assume be there all the time, opening it in app and keeping it invisible until needed is probably the best way to go.
Maybe a timer on the main window that watches a property in App and opens the window indicated there when the property is set. Then they would all be owned by the main window.
I tried that and couldn’t get it to work. It still ended up linked to the visible window even though I opened the floating window while the harness window was still visible.
Sadly, I had to give up. On the Windows version, the floating window will be a mere Document-type window.
I think I know what you can do to have a window that stays on top : display a global floating window in app, which you hide in app.deactivate and show back in app.activate.
Since that window is not displayed by the others, it has it’s own hierarchy.
How about using a call to the win32 API to “manually” set the parent window of a new window? I believe you van set the parent to whatever other window you can identify with its hwnd property. see here
If that does not work, there is also a window owner that can be set, but as far as I understand, it is more complicated. And I never used the window owner.
Michel, I really thought you were onto something with your idea, but alas, it exhibited exactly the same problem.
I thank you all for your contributions, but alas, I’ve given up and made it a regular document window on both platforms (which may be better anyway, ironically). I did incorporate Michel’s idea to hide/show on app activation, so it acts somewhat like a floating window in that respect.
