Hello people!
Whenever I make any OpenGL-program in win98 the window is still visible. Is that normal?!
What do I have to do to create a REAL full screen, so that I dont see any toolbar or windowframe???
IF I realized that then… does it support my GeForce2 in the harwareaccelaration?!
I know that DirectX has something like HAL and HEL which is switching and controling that part, is it possible to run that under OpenGL too, so that I use some DirectX-HEL/HAL withinn the OpenGL stuff? Or has OpenGL it’s own Harware-libraries?!?!
Just create a maxumized window without bordersm then Windows understands that you want to takeover the whole screen and ‘hides’ the taskbar for you.
Opengl can in windows use some of the DX libraries, but you should not notice that, and when you use opengl in a window you should only use opengl, not mix opengl and dx ( even if some drivers might let you)
I wish it was that simple…
I have one additional toolbar on my desktop with “always on top” setting
and sometimes @#$%&* Widows keeps on displaying it over fullscreen GL app.
I noticed occurence of the effect depends on which desktop element had focus while launching GL app.
And no, it is not becouse I setup my window badly - I get this effect even in Quake2/3 or SDL applications.
first of all, set your video mode by calling ChangeDisplaySettings() with the CDS_FULLSCREEN flag. this tells win32 to set the video mode but not mess around with desktop icons and repositioning of other windows.
then call AdjustWindowRectEx() - initalise RECT struct to something like { 0, 0, 640, 480 } before calling, and make sure you supply the same window style/extended style as when you created the window (or you could use it as input to CreateWindowEx). note 1: this doesn’t work on WS_OVERLAPPED style, so use WS_POPUP - you want this style anyway because by default it has no border or title bar. note 2: make sure you use rect.top and rect.left for your top/left corner, it needn’t be 0, 0 after AdjustWindowRectEx().
if you’ve created the window first, now you’ll want to call SetWindowPos(): make sure that the hwndInsertAfter param (i think it’s the second param) is HWND_TOPMOST and that you specify left/top/width/height like so:
rect.left, rect.top, rect.right -rect.left, rect.bottom - rect.top
rect being the RECT struct you supplied to AdjustWindowRectEx(). note: make sure you don’t specify the SWP_NOSENDCHANGING flag, this stupidly crashes win9x in fullscreen.
or you could call AdjustWindowRectEx() first, and then call CreateWindowEx() with WS_EX_TOPMOST style and the same rect crap as above.
I do not think I’ve ever had to use the TOPMOST flag to get the window on top. I just use SetWindowPos then SetForegroudWindow.
Setting TOPMOST is scary because it means that if the program locks up (but the rest of the system is still running) it will be a pain to actually do anything about except reboot. If the window is not TOPMOST, at least other windows can get on top of it when you Alt-Tab.
With Windows 2000/XP where you can Ctl-Alt-Del to get the security window, that is not really a problem anymore. I’m just saying that TOPMOST may not be nessecary.
I just spent a few days with this one (or at least a related “bug”). For those of you that don’t know, SetForegroudWindow does not do sh*t under Windows versions other than 95/NT4. Under 98/ME/2K/XP/.NET you are facing the following dilemma:
You are not allowed to set the foreground window unless you are already the foureground application!
Go figure! (thanks alot M$)
If you care to get a headache, you can read the Windows source for GLFW v2.2.3. It does some horrible tricks to work around this, and I still have some problems if GLFW is used from Visual Basic.
mattc: MSDN says this about SetWindowPos (last paragraph): “If an application is not in the foreground, and should be in the foreground, it must call the SetForegroundWindow function.”
I interpret this as: you can’t be topmost if you’re not foreground. I may be wrong though… (as usual, the MS docs aren’t as clear as one would sometimes wish)
[This message has been edited by marcus256 (edited 10-29-2002).]
the foreground window/application thing means only the app with the keyboard focus can bring windows up to front, which is why sometimes SetWindowPos does nothing…
regarding the foreground/topmost thing: they’re separate things - essentially, win32 has two Z-order lists (or groups) for displaying windows, one is topmost, the other not topmost. SetForegroundWindow works within the group you’re in - so topmost windows are always over the “not-topmost” (normal) windows. this is why you want to use the topmost style - taskbar is also topmost, so the only way to “cover” everything is to use the style yourself, and then bring yourself up front.
regarding the bug: you’re allowing the user to make a mess, basically - you’re not taking care of issues in your multitasking environment (even users can multitask sometimes ). if you’re full-screen and the user switches away somehow to another app or the desktop, minimise yourself and restore the desktop’s video mode and when you regain the focus, restore your video mode and your renderer. or better yet, switch to windowed rendering: it doesn’t effect the rest of the app in any way after the setup, is very trivial to add to any app, and makes on-the-fly debugging possible.
personally, i think anything that doesn’t support windowed mode is less professional. it’s sometimes just plain annoying that you can’t pause your game or whatever, switch to a normal app to quickly find something for a friend who’s just called you, tell him what he wants to know, and then go back to the game… i don’t wanna quit the game, start notepad, look briefly, close notepad and restart the game
[edit]chronic typos
[This message has been edited by mattc (edited 10-30-2002).]
the foreground window/application thing means only the app with the keyboard focus can bring windows up to front, which is why sometimes SetWindowPos does nothing…
…which is exactly why you need SetForegroundWindow to work for you even if you are not the foreground app, if your window needs to be on top (e.g. a fullscreen window), right?
regarding the bug: you’re allowing the user to make a mess, basically - you’re not taking care of issues in your multitasking environment (even users can multitask sometimes ). if you’re full-screen and the user switches away somehow to another app or the desktop, minimise yourself and restore the desktop’s video mode and when you regain the focus, restore your video mode and your renderer.
I do all that. When the window loses focus (e.g. through an ALT+TAB), it is automatically iconified, and the desktop resolution is restored. Whenever “my” window is selected/activated again, it changes back to the custom video mode and maximizes the window (and puts it on top).
personally, i think anything that doesn’t support windowed mode is less professional. it’s sometimes just plain annoying that you can’t pause your game or whatever, switch to a normal app to quickly find something for a friend who’s just called you, tell him what he wants to know, and then go back to the game…
…which is why the GLFW fullscreen mode has been designed the way it is. Of course you can also use windowed mode instead of fullscreen mode, but it’s up to the app to select that. And I think it’s really trivial for an app to let the user select windowed or fullscreen mode. It is also trivial to detect if a fullscreen window has been iconified, and place the game (or whatever type of app it is) in paused mode.
BTW, thanks for the topmost/not topmost information. Perhaps this is a clue to why Visual Basic progrmas that use GLFW behave differently than e.g. C/C++ programs (even if it’s exactly the same code - the code is in a DLL, so it shouldn’t matter from which program it is executed). Perhaps VB programs somehow have a different default topmost class, or whatever?
[This message has been edited by marcus256 (edited 10-31-2002).]
sort of, i assume the vb runtime takes care of these low-level details… since all that stuff is accessible from code, essentially any app can control its behaviour as it likes in this regard. the bottom line is, use SetWindowPos with the topmost style on, and whenever you get focus or receive an activation message, call SetForegroundWindow, that way you can guaranteee that your app is the only visible thing
Originally posted by mattc: use SetWindowPos with the topmost style on, and whenever you get focus or receive an activation message, call SetForegroundWindow, that way you can guaranteee that your app is the only visible thing
Shouldn’t it be the other way around? First get focus / foreground, then topmost? Or perhaps it doesn’t matter.
when you get focus, set the topmost style. should take care of everything, gaining focus implies you’re at the top of the pile anyway. there might be issues if you’re destroying and recreating the window on the fly… i prefer to keep the window alive and only destroy&recreate the gl context if the bpp changed between desktop and my own video mode
). if you’re full-screen and the user switches away somehow to another app or the desktop, minimise yourself and restore the desktop’s video mode and when you regain the focus, restore your video mode and your renderer. or better yet, switch to windowed rendering: it doesn’t effect the rest of the app in any way after the setup, is very trivial to add to any app, and makes on-the-fly debugging possible.