[MacOS] Window doesn't get focus

BlitzMax Forums/BlitzMax Programming/[MacOS] Window doesn't get focus

GfK(Posted 2012) [#1]
I initially posted this as a bug report, but I'm not really sure it is as some googling suggests that Apple think a window forcing focus to itself is a very very bad thing (even if the full-screen game already had focus anyway?!). But I digress...

Consider this code:
Strict

Graphics 1024,768,32

Local isWindowed:Byte = False

While Not KeyDown(key_Escape)
	PollEvent()
	Cls
	If KeyHit(key_space) And (Not isWindowed)
		Graphics 1024,768,0
		isWindowed = True	
	EndIf
	DrawText "PRESS SPACE FOR WINDOWED MODE",50,10
	If CurrentEvent.id = EVENT_MOUSEMOVE
		DrawText "MOUSEMOVE",50,50
	EndIf	
	Flip
Wend

End


It starts in fullscreen. Move the mouse around and you'll see it's catching events nicely as it displays "MOUSEMOVE" when you move the mouse. Now hit SPACE, and do the same. The window is at the front, but does not have focus and is not capturing events.

Clicking in the window also does not give it focus. The only way I have found around this, is to manually click outside of the window, THEN click in it. I have no knowledge at all of Objective C and have no idea how to fix this, or if it can be fixed.

There is actually another way around the problem, as I've noticed that if the game starts in windowed mode, then goes fullscreen, and finally back to windowed, the problem doesn't happen. This looks very ugly though at game startup, and all of this leads me to believe that a solution is possible.

My game is meant to be going on sale in a couple of weeks so I'm in desperate need of a solution here.


therevills(Posted 2012) [#2]
Dave, have a look at Jakes thread here:http://www.blitzmax.com/Community/posts.php?topic=94364

It might help ya.


GfK(Posted 2012) [#3]
Thanks -already saw that and it doesn't really help.

I guess what I'm really looking for here is a modification to glgraphics.macos.m which corrects the initial behaviour when switching from fullscreen to windowed and ensures that the window has focus. I'm pretty sure it'll fail on functionality QA if I submit it like this.

[edit]...and looking at the sales numbers for Mac compared to PC, I'm pretty sure I'm not going to bother supporting Mac any more after this. Too much effort for too little reward.

Last edited 2012


Corum(Posted 2012) [#4]
I'm glad to notify that here, under Snow Leopard 10.6.8, the app doesn't lost its focus.
Tested your snippet both in debug and release mode, with Max 1.48 and XCode 4.2
Once again I'm sad to remind that 10.6.8 was the latest real OS from Apple.
What SO version are you running?


GfK(Posted 2012) [#5]
It's 10.8, which I *have* to support.


Raz(Posted 2012) [#6]
There is actually another way around the problem, as I've noticed that if the game starts in windowed mode, then goes fullscreen, and finally back to windowed, the problem doesn't happen. This looks very ugly though at game startup, and all of this leads me to believe that a solution is possible.
Not really fixing things, but can you have a titlebar-less splash screen to start?

I don't know too much about OSX, but is there any indication as to what might be the focussed app (even though it seems either Blitz or OSX already things the blitz window is focussed)?


GfK(Posted 2012) [#7]
I've solved it thus.

Just create a 2x2 window at startup, but only if the game prefs file says it's going to launch in fullscreen mode. I don't need to do any of this if the game is starting in windowed mode (which it may do if that's what the user sets it to). It's not an elegant solution, but it works, and you don't even notice the tiny window appearing for a split second - certainly not as much as the mouse pointer not being there, anyway.

I'm sure there's a better way than this and I don't know if it'll get through QA, but for now, with time ebbing away, it'll have to do. Delivery of the first release candidate for both PC and Mac is due, like, now!

In the meantime if anybody knows of an Objective C-based solution to fix up glgraphics.macos.m's window creation code, then I'm all ears.


Grey Alien(Posted 2012) [#8]
Like you, I make and destroy a small window at start up (for Full Screen mode) so that stuff works properly.

Last edited 2012


GfK(Posted 2012) [#9]
Good to know, thanks.


therevills(Posted 2012) [#10]
Like you, I make and destroy a small window at start up (for Full Screen mode) so that stuff works properly.


LOL! I've just spotted that code in commontypes.bmx.

[bbcode] ?MacOS
'Due to a problem with ccGetActiveWindowOSX() where if you start the game in full-screen mode
'it is never able to get a proper handle for windowed mode after you toggle to windowed mode,
'we need to ALWAYS start in windowed mode.
'So if the game is about to start in Full-screen mode, we need to quickly make and destroy a
'small window first like this.
If FullScreen Then
Graphics 10,10,0
EndGraphics()
EndIf
?[/bbcode]

Last edited 2012


Grey Alien(Posted 2012) [#11]
Yup that's it. This is why my framework is cool, because I've figured out all this crazy shit and solved it. /end blow own trumpet mode

Last edited 2012


therevills(Posted 2012) [#12]
I totally agree! You did heaps of groud of work, so glad a grabbed my copy :)

@Dave, I'm suprised that you havent you into this issue before - maybe you have and fixed it before?

Last edited 2012


SLotman(Posted 2012) [#13]
This only happens in the latest MacOS?

Edit: Just tested on Lion, the example app does the same thing - the strange thing is... none of my games has that problem.

So I tested it further and guess what? There is no bug in the compiled app!

It's something to do with Blitzmax IDE. Just run the compiled .app and see for yourself - your app won't loose focus when switching from fullscreen to windowed mode - so you won't need the "small window" after all :)

A 'quick fix' for this when you're testing your game - just click on the window bar (on top of the screen - the 'main' bar for every window on MacOS) and not on the window itself, and you regain your focus.

Last edited 2012


Grey Alien(Posted 2012) [#14]
How strange!

Well I'm needing to do that funny fix so I can get a window handle later to deal with mouse positioning related to the window coordinates.