The first OpenGL command blocks MessageBox and causes further Runtime Errors

I have a following problem. When I create a window that completely covers the screen,

(that means, if the screen resolution is 1024x768, so the window is the same size: 1024x768, exactly!, nothing like 1023x768 or 1024x769)

(wndClass.style: CS_HREDRAW | CS_VREDRAW | CS_OWNDC)
(dwStyle of the window: WS_POPUP | WS_SYSMENU | WS_CLIPCHILDREN | WS_CLIPSIBLINGS)

and after initializing OpenGL just clears the client area of the window with black:

glClear(GL_COLOR_BUFFER_BIT);
SwapBuffers(hDeviceContext);

I call MessageBox and don’t see the message window. Seems like it “hidden” under the my black fullscreen window. The modal effect is present, I can move mouse cursor, but I can’t click OK or Cancel button, the message is not visible. When I press Enter key, the message window shuts down, like after click on OK button.

But sometimes it causes an access violation error in user32.dll (MessageBox defined there). That’s very strange behaviour. I have read some info on this and they say that OpenGL driver handles the case when the viewport area is exaclty as screen resolution, the driver treats it as the special case and applies its low-level optimizations (some say they are ugly and may cause various exceptions in runtime). May be that’s the point! But, I have some doubts.

For now, the only solution is set the fullscreen window size as [width + 1]x[height]. In this case, everything works just fine, but I don’t think this is a truly way out.

What could be wrong with this? Is there an explanation or solution how to get rid of it?

Two questions:

  1. Does the window have the TOPMOST style? If I remember correctly this is an extended style and not part of dwStyle.
  2. Does the message box have the main window as owner or just NULL?

If 1 is true and the answer to 2 is NULL it’s no surprise that the message box will be behind the window. A topmost window will always be in front of the non-topmost messagebox.

  1. No. I don’t use extended window styles, only standard with prefix WS_.
  2. The MessageBox call is like the following:

MessageBoxA(hWindow, ‘This is demo version. You need to purchase a key to disable this message every 60 seconds.’, ‘DEMO’, MB_OK);

I tested this situation on my three computers. Two of them have this bug (message is “hidden”), but the other one doesn’t - it shows the message over the window.

So, what kinds of graphics hardware do you have in these systems? This sounds like a driver problem.

They are different. Notebooks have ATI Radeon’s videocards. The old desktop computer has integrated Intel video system (without shader support including many other stuff). At the moment I’m pretty sure there are 2 ways OpenGL driver behaves when it sees the window:

  1. The client area is not as the screen resolution. It can be smaller or larger, but not equal. This mode is supported well by most OpenGL drivers, that’s why it works maximally stable on various systems.

  2. The client area is exactly as the screen resolution. This mode is special and I think OpenGL driver behavior here is something different in some way. Because, there is always something that works wrong. My first computer distorts the loaded textures while switching into fullscreen mode and back. It also generates Runtime Error in ‘user32.dll’ which is quietly unacceptable. Two other computers hide VLC video player and every MessageBox’s call. Looks like OpenGL creates a special layer just to “cover” everything else, maybe it thinks they are not useful. He may think that, but I don’t! Now I’m pretty sure that it is not a full bug list caused by this mode.

The game engine should work correctly regardless of what drivers are installed. The second mode gives a lot of trouble and mistakes, so I preferred the first one with a little patch in window size like [width+1]x[height] or [width]x[height+1].

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.