Problem - Event Handling for an OpenGL window - and MFC/Win32 App

Hello.
Basically I have an MFC app that spawns an openGL window implemented using the windows SDK (WIN32). This opengl window has its own event handler. It is spawned when a button is clicked in the main application. The problem is I need to click somewhere outside of the entire application (i.e. activate another application or click the taskbar slot [for lack of a better term] for the opengl window - deactivate then reactivate [bring to foreground] the window) and then reactivate the opengl window in order for it to receive messages again (by again I mean it must have initially recieve windows messages in order for it be created, displayed and the openGL scene rendered). This is highly undesirable. I want the window to immediately respond to messages after it is spawned. VERY SIMPLE TEST CODE ILLUSTRATING THIS PROBLEM IS at http://xtopia0.tripod.com/testcode/openglwintest.zip (right-click and do a “save target as” to download… tripod is screwy)
Any Ideas? Is there a better way to spawn an opengl rendering window from an MFC app? (And yes I know ideally I should not use MFC at all. But I’ll need it after I solve this problem.)

Thanks.
ks

This is how I create a good opengl window.
Full screen:
int main(int argc, char **argv){
glutInitWindow(&argc, argv);
glutInitDisplayMode(GLUT_DEPTH | GLUT_RGBA);
glutGameModeString(“640x480:16@16”);
glutEnterGameMode();

or windowed:
void window(GLsizei w, GLsizei h){
glViewPort(0, 0, w, h);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glFrustum(-100w/h, 100w/h, -100, 100, -100, 100);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
}

loopguru,

What you have to do is, periodically send WM_PAINT events to your OpenGL window in order for it to get redrawn. Naturally, this does not happen automatically in regular Windows applications (since that would waste a lot of performance).

One easy way of achieving this is to intercept WM_IDLE events and send WM_PAINT messages to your GL window. Another way would be to setup some kind of timer that gets called, say, 30 times a second and then do a window redraw from the timer routine.

HTH

Thanks Asgard.
The problem is not that the scene is not being painted. In fact I only want the scene to be repainted after WM_SIZE , WM_MOVE , etc. events and when I actually need to re-render the scene. The problem is that after the window is created and the scene is initially rendered, I need to deactivate (send to background) and then reactivate that window in order that it respond to messages via its message handler.

Originally posted by Asgard:
[b]loopguru,

What you have to do is, periodically send WM_PAINT events to your OpenGL window in order for it to get redrawn. Naturally, this does not happen automatically in regular Windows applications (since that would waste a lot of performance).

One easy way of achieving this is to intercept WM_IDLE events and send WM_PAINT messages to your GL window. Another way would be to setup some kind of timer that gets called, say, 30 times a second and then do a window redraw from the timer routine.

HTH[/b]

you gotta be kidding, there are 20 or so cpp/h files to look through… which one has the relevant code? 8)

anyway, the basic win32 glut library code for window management is not really recommended past the initial learning stage… in other words, microsoft is telling you, for best results, do your own message pump… it’s not that scary and i’m pretty sure there are tons of examples to set it up in win32 graphics articles.

Sorry.
I was in a hurry. I thought I mentioned which files are relevant(they are oglwindow.* and mainfrm.*). Anyway, the problem was a foolish one: after the typical ShowWindow( … ) and UpdateWindow( … ), I call:
SetForegroundWindow( … ) ; // 1
SetCapture(hWnd) ; // 2
SetFocus(hWnd) ; // 3
(1) and (3) are completely redundant as the window which was just created is by default the foreground window and has focus. The source of the problem is (2) which “captures” the mouse input. It should not capture input outside the window, though. No time now to harp on it, though. Removing (2) solves the problem.

yes, the way mouse capture is, it’s better to use it as microsoft intended… losing focus will break the capture, for example, so you have to handle all the cases or your program starts behaving like it’s drunk