Alt-Tab in DirectX Applications
Author
Is there a way to allow the use of ALT-TAB in a DirectDraw application using C++? My problem is that I am getting errors while my program is running, but I cannot see them since DirectDraw refuses to relinquish the screen until the program is finished. I have tried simply eliminating the DDSCL_EXCLUSIVE flag when calling SetCooperativeLevel, but then I get unhandled exceptions when initializing DirectDraw. Any help is appreciated!
Do a search on it... here or on MSDN. It has been answered here before I know (I think on the fron page, too 
) and there is an article on MSDN.
) and there is an article on MSDN.
The ALT+TAB sequence:
User pressed Alt+Tab -> focus is no longer on the game -> no messages received until user resumes the game -> user resumes the game -> device and bitmaps are lost -> you need to restore the device and the bitmaps -> continue the game...
User pressed Alt+Tab -> focus is no longer on the game -> no messages received until user resumes the game -> user resumes the game -> device and bitmaps are lost -> you need to restore the device and the bitmaps -> continue the game...
You say you''re getting errors. Are you being informed of these errors through message boxes? If so, THAT is the problem, not direct draw. Most of the time message boxes end up being in a mode where you can not get them to relinquish command until you''ve clicked a button, and direct draw can''t switch off until the message box has given back control. My recommendation is to log errors in a log rather than using message boxes, then if it''s a horrible evil error quit the application. You can then look at the log to see what the horrible evil error was.
If that''s not the problem, then I don''t know what is. Every time I''ve hit Alt+Tab in any DirectGraphics application it works--unless the program threw up a message box or C++ Debugger interupted the program (which also steals control without letting DirectX deactivate itself). If you must use message boxes, are planning on using the debugger, or the problem isn''t one I''ve described, rebuild your activation to allow for windowed mode. There''s an article someplace on GameDev, do a search. That will allow you alt+tab to your hearts content, interupt the thread, or whatever. Makes things MUCH easier for debugging (The logger is also helpful, especially for those pesky release only errors that occur because of different memory handling, or the fullscreen only errors.)
If that''s not the problem, then I don''t know what is. Every time I''ve hit Alt+Tab in any DirectGraphics application it works--unless the program threw up a message box or C++ Debugger interupted the program (which also steals control without letting DirectX deactivate itself). If you must use message boxes, are planning on using the debugger, or the problem isn''t one I''ve described, rebuild your activation to allow for windowed mode. There''s an article someplace on GameDev, do a search. That will allow you alt+tab to your hearts content, interupt the thread, or whatever. Makes things MUCH easier for debugging (The logger is also helpful, especially for those pesky release only errors that occur because of different memory handling, or the fullscreen only errors.)
Author
You see, that''s the problem. I''m not creating the message box, MSVC is. I think it''s fairly safe to assume it''s an unhandled exception, but even so I don''t know where in the program the problem is occuring. Is there a way to tell MSVC to create an error log?
Not that I know of, if VC is intercepting the unhandled exception I'd say you have to go for windowed mode. Also, you could create a function in a logger for what I call "Spam messages", messages that tell you EXACTLY what's going on, which part of the code was just executed, etc.. When the log suddenly stops, you know that the error occured after the last message you got, so look in that area for your exception. Then delete the spam messages when they aren't needed anymore.
Also, if you happen to have a second computer on hand, use remote-debug. One computer runs the remote client, and it'll run the game on full screen, while the other runs MSVC, compiles, and controls the program execution. When it gets an unhandled exception (I find that usually occurs when I try to dereferance a null pointer) it will go to the computer NOT in fullscreen mode and then you can see what's going on.
[edited by - Erzengeldeslichtes on October 14, 2003 3:04:28 PM]
Also, if you happen to have a second computer on hand, use remote-debug. One computer runs the remote client, and it'll run the game on full screen, while the other runs MSVC, compiles, and controls the program execution. When it gets an unhandled exception (I find that usually occurs when I try to dereferance a null pointer) it will go to the computer NOT in fullscreen mode and then you can see what's going on.
[edited by - Erzengeldeslichtes on October 14, 2003 3:04:28 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
