Carbon+agl Fullscreen problems
Post: #1
Hi, I recently bought an ibook to port my 3d engine to OS X and Im having problems with fullscreen task switching. I haven't been able to find a related post using the search feature of this forum.
As I am new to this OS I dont know what information to provide so please bear with me if im not providing appropiate details:
Everytime I press alt+command(that apple key)+esc to switch active app, my fullscreen OpenGL app exits with signal 15 (SIGTERM). I am using carbon and agl, and my code isnt using thirty party libraries, messing with signals nor I call exit() at any point. I dont have any problems when running in windowed mode.
All my processed events are dispatched through CallNextEventHandler too and the return value is used, I never assign result values directly.
Im using XCode 2.2 on Tiger.
events im processing:
Is there any housekeeping im missing that causes this behaviour?
Thankyou in advance.
As I am new to this OS I dont know what information to provide so please bear with me if im not providing appropiate details:
Everytime I press alt+command(that apple key)+esc to switch active app, my fullscreen OpenGL app exits with signal 15 (SIGTERM). I am using carbon and agl, and my code isnt using thirty party libraries, messing with signals nor I call exit() at any point. I dont have any problems when running in windowed mode.
All my processed events are dispatched through CallNextEventHandler too and the return value is used, I never assign result values directly.
Im using XCode 2.2 on Tiger.
events im processing:
Code:
{ kEventClassWindow, kEventWindowGetIdealSize },
{ kEventClassWindow, kEventWindowBoundsChanging },
{ kEventClassWindow, kEventWindowBoundsChanged },
{ kEventClassWindow, kEventWindowResizeCompleted },
{ kEventClassWindow, kEventWindowDragCompleted },
{ kEventClassWindow, kEventWindowActivated },
{ kEventClassWindow, kEventWindowDeactivated },
{ kEventClassWindow, kEventWindowClose },
{ kEventClassWindow, kEventWindowClosed },
{ kEventClassWindow, kEventWindowHidden },
{ kEventClassWindow, kEventWindowShown },
{ kEventClassWindow, kEventWindowZoomed },
{ kEventClassMouse, kEventMouseDown },
{ kEventClassMouse, kEventMouseUp },
{ kEventClassMouse, kEventMouseMoved },
{ kEventClassMouse, kEventMouseDragged },
{ kEventClassMouse, kEventMouseWheelMoved },
{ kEventClassKeyboard, kEventRawKeyDown },
{ kEventClassKeyboard, kEventRawKeyUp },
{ kEventClassKeyboard, kEventRawKeyRepeat },
{ kEventClassKeyboard, kEventRawKeyModifiersChanged }Is there any housekeeping im missing that causes this behaviour?
Thankyou in advance.
Post: #3
To expand on OneSadCookie's surprisingly brief message, command-tab is the 'switch applications' key combination. It won't normally work in AGL full-screen mode. You may, however, be able to catch the event, switch out of full screen mode, and switch to the next application, if that's the desired behavior.
Post: #4ThemsAllTook Wrote:To expand on OneSadCookie's surprisingly brief message, command-tab is the 'switch applications' key combination. It won't normally work in AGL full-screen mode. You may, however, be able to catch the event, switch out of full screen mode, and switch to the next application, if that's the desired behavior.
Yes, I noticed command-tab didnt work when fullscreen and was also puzzled as why I wasnt getting a dialog to choose task when pressing command-option-escape while in fullscreen (I get it when in windowed mode). I thought I might be doing something wrong.
If command-tab doesnt work in fullscreen, then, whats the appropiate way to switch from a fullscreen game to desktop and then back? (will dig into keyboard events to trap cmd-tab for now)
On a side note, whats the expected behaviour for runtime windowed/fullscreen switching?
I only own one game for my Mac (World of Warcraft) and it uses command-m while a forum search reveals other combinations like command-h or something and I have no way to know whats a legacy os9 convention, whats expected on OS X and whats arbitrary.
Sorry if those questions are obvious to veterans, I hope im not coming off as a slacker that wants to be spoon fed, Im searching all over the place and studying code. Im new to macs (Im a windows and linux programmer), and I am allready overwhelmed trying to absorb lots of new information and Mac ways.
It allready felt like a personal triumph to make my first Mac app and get it to work in both fullscreen and windowed mode. Not to mention finally getting the windows & events to work right when compiling from command line with makefiles... (sorry, im ranting).
Thanks for your help.
Post: #5
When you're in a true full-screen mode, you've effectively disabled the window server. That disables command-tab, and reduces command-option-escape from providing a window with a choice, to just forcing the full-screen app to quit.
There is no convention for what to do to switch between full-screen and windowed mode. Blizzard apps use command-M, so that's a reasonable choice. Since you probably don't have too many command-key shortcuts, you could make command-M (usually "minimize"), command-H (usually "hide application") and command-Tab (usually "switch applications") all do the same thing...
There is no convention for what to do to switch between full-screen and windowed mode. Blizzard apps use command-M, so that's a reasonable choice. Since you probably don't have too many command-key shortcuts, you could make command-M (usually "minimize"), command-H (usually "hide application") and command-Tab (usually "switch applications") all do the same thing...
Post: #6
You cannot display any OS dialogs if you use a full screen AGL context. The workaround is to capture the display using CoreGraphics, and creating a window spanning the whole screen instead. The only drawback is that you have to do some additional mucking about to set up the shielding window and the hide dock & menubar. The CG way is more flexible than going the AGL route.
Post: #7
See Shoot Things for example code of catching Cmd-Tab and switching back to a window.
(Shootroller.m sendEvent and toggleFull. Not the cleanest code, but it is free...)
(Shootroller.m sendEvent and toggleFull. Not the cleanest code, but it is free...)
Post: #8
Thanks for the explanations. They helped 
Looking at the video code right now. Im using Carbon instead of Cocoa but the concepts seem transferable. It will certainly ease the development. Thanks for the link.
Looking at the video code right now. Im using Carbon instead of Cocoa but the concepts seem transferable. It will certainly ease the development. Thanks for the link.
