Window shifting up on Windows
BlitzMax Forums/MaxGUI Module/Window shifting up on Windows
| ||
Probably related to the WINDOW_CENTER fix put in 1.39 I create a centered window gadget. Then I load a position into my settings type and then do this: SetGadgetShape(mainWindow, settings.windowX, settings.windowY, settings.windowWidth, settings.windowHeight) To restore the window to it's previous location and size. This works perfectly on mac, but on windows every time the application launches the window moves up the height of the title bar for the window. I didn't do much testing with 1.38 on windows so I can't say 100% this is new with 1.39 but it doesn't behave the same on mac and PC at the very least. |
| ||
Where is the problem with using directives??MacOS SetGadgetShape(mainWindow, settings.windowX, settings.windowY, settings.windowWidth, settings.windowHeight) ? Okay, this is no fix, but it will help you until it is fixed... :> |
| ||
Thanks, my current fix is on windows to shove the window down about 25 pixels (haven't bothered testing to get size exact yet) since I need it to resume it's previous size and position, so I need to setgadgetshape on both. |
| ||
Hmmm... This used to be a common problem between the MaxGUI drivers, but I remember dedicating serious amounts of time on each platform trying to eliminate them. Strangely though, I can't reproduce this... Try the following code example with different flags. Closing the window, opens a new one exactly where the old one used to be, so I'm pretty confused:' createwindow.bmx Import MaxGui.Drivers SuperStrict Const FLAGS:Int = WINDOW_TITLEBAR|WINDOW_RESIZABLE|WINDOW_MENU|WINDOW_CLIENTCOORDS Global winX:Int = 100, winY:Int = 100, winW:Int = 320, winH:Int = 240 RecreateWindow() While True WaitEvent Print CurrentEvent.ToString() Select EventID() Case EVENT_WINDOWCLOSE Local tmpGadget:TGadget = TGadget(EventSource()) winX = GadgetX(tmpGadget) winY = GadgetY(tmpGadget) winW = GadgetWidth(tmpGadget) winH = GadgetHeight(tmpGadget) FreeGadget tmpGadget RecreateWindow() End Select Wend Function RecreateWindow() Print "winX: " + winX + ", winY: " + winY + ", winW: " + winW + ", winH: " + winH ActivateWindow CreateWindow("My Window",winX,winY,winW,winH,Null,FLAGS) EndFunctionThe only thing I can think of, is maybe you have a toolbar on the window? In which case, make sure you add the toolbar and set the icons, before you position the window using the saved settings. Doing so before, might cause a shift of the toolbar height. But then again, you did say it was a shift by the titlebar height, which although could coincidentally be roughly the same, would disprove this theory. |
| ||
I gave your test a try and it works fine. However I modified it to be closer to what I use for my window and managed to re-create the problem' createwindow.bmx Import MaxGui.Drivers SuperStrict Const FLAGS:Int = WINDOW_TITLEBAR | WINDOW_CLIENTCOORDS | WINDOW_RESIZABLE | WINDOW_ACCEPTFILES | WINDOW_HIDDEN | WINDOW_CENTER | WINDOW_STATUS Global winX:Int = 100, winY:Int = 100, winW:Int = 320, winH:Int = 240 RecreateWindow() While True WaitEvent Print CurrentEvent.ToString() Select EventID() Case EVENT_WINDOWCLOSE Local tmpGadget:TGadget = TGadget(EventSource()) winX = GadgetX(tmpGadget) winY = GadgetY(tmpGadget) winW = GadgetWidth(tmpGadget) winH = GadgetHeight(tmpGadget) FreeGadget tmpGadget RecreateWindow() Case EVENT_APPTERMINATE Exit Case EVENT_MENUACTION exit End Select Wend Const MENU_EXIT:Int = 101 Function RecreateWindow() Print "winX: " + winX + ", winY: " + winY + ", winW: " + winW + ", winH: " + winH Local myWindow:TGadget = CreateWindow("My Window", 100, 100, 320, 240, Null, FLAGS) Local filemenu:TGadget = CreateMenu("&File", 0, WindowMenu(myWindow) ) ?win32 CreateMenu("E&xit",MENU_EXIT,filemenu,KEY_Q, MODIFIER_COMMAND) ? UpdateWindowMenu(myWindow) 'ActivateWindow(myWindow) SetGadgetShape(myWindow, winX, winY, winW, winH) ShowGadget(myWindow) EndFunction the problem comes from the menu bar. Once you call UpdateWindowMenu() to make the menu bar visible it starts shifting up on the reloads. Which makes sense that it wouldn't do it on mac since the menu bar is outside the window on mac. If you change it to call UpdateWindowMenu() after the setGadgetShape() it doesn't shift. I'm not sure if this means I was just doing it wrong, or if there is a bug related to positions and menus with clientcoords... |
| ||
Ah, I think I see what the problem is. Technically your window should be created with the 'WINDOW_MENU' flag style constant, as it is destined to contain a window-menu. A bit of history: some would argue this should throw an error if you try to attach a menu to a window without this flag (in fact, I think FLTKMaxGUI probably does throw a hissy-fit). The reason why it doesn't in Windows is because implementation details in the original BlitzPlus code (that MaxGUI borrowed from) meant that omitting the flag wasn't really a problem. And when the new BMax Windows driver was being developed, it inherited this resilience so that old code didn't break if recompiled. Anyhoo, add the flag in, and it seems to work as expected irrespective of whether UpdateWindowMenu() is called before or after SetGadgetShape(). And you'll get the added bonus that FLTKMaxGUI will be happier too! Hope this helps! Edit: I've added a line to MaxGUI v1.39b's docs for WindowMenu() and UpdateWindowMenu() to make this a little more explicit. |
| ||
I was me after all! the world makes sense again. Thanks for all the help Seb, updated my code with flag (which I should have had all along but just lost it in the long flag list I guess) and everything seems fine. |
| ||
Awesome! Glad to hear! :-) Happy MaxGUI'ing! |