Window shifting up on Windows

BlitzMax Forums/MaxGUI Module/Window shifting up on Windows

ima747

(Posted 2010) [#1]

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.

d-bug

(Posted 2010) [#2]

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... :>

ima747

(Posted 2010) [#3]

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.

SebHoll

(Posted 2010) [#4]

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)
EndFunction

The 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.

ima747

(Posted 2010) [#5]

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...

SebHoll

(Posted 2010) [#6]

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.

ima747

(Posted 2010) [#7]

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.

SebHoll

(Posted 2010) [#8]

Awesome! Glad to hear! :-)

Happy MaxGUI'ing!