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

[loopguru]

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

[vladk]

Although I did not quite well understand the problem, it seems to me that you are having trouble with message dispatching, or you have forgotten to handle a message.
MFC is pretty buggy, and I suggest standard C way of creating an OpenGL window.

It is very simple. Just open a standard, single bordered window, set PixelFormat
Descriptor for OpenGL, and respond to either
WM_PAINT or WM_IDLE messages to render a
scene, depending on what do you need.

For that you can use App Wizard, and set up
a non-MFC WinAPI console application.

For OpenGL, MFS will not be of certain use,
since you are thus adding another layer
between your core and OpenGL engine.

If you wish, I might brew an example code for
ya...

[loopguru]

Thanks and, sure, I appreciate seeing anyone else's implementation (you almost always learn something from it) ... though I solved my problem. I called SetCapture( ... ) which was intercepting all the mouse input. As yucky as it is, I require MFC, because the app requires many controls - some of which are more complex than buttons and the like (and quite frankly I don't have the time to delve into the "raw" win32 programming needed to code these)

I have another question maybe you can tackle. Its more general: I have my "opengl render window" which is spawned from the main application. I would like a thread to either handle the window and the rendering process OR a thread just to do the rendering.
(a) Which approach is more practical and EFFICIENT.
(b) Please provide suggestions on how to do this.

Thanks
ks

[vladk]

First of all, why using threads? If your application will use real-time rendering, no threading is needed. On the other hand if you think to draw complex images, ie. so complex that they are drawn in >2 sec, yes,
perhaps you should use a thread, but not necessarilly.

Threads do not speed up your application. They only allow multitasking, thatis performing more than a single task at a time.

Since Win32 is event-based OS, until one event finishes processing (for example your rendering function), no other events shall be processed, but stacked in the messaging pipeline.

Thus, in that case, you may want another thread to respond to *Stop*, or *Close* or *Cancel* buttons. You get my point.

Anyway, if you NEED a thread, the best use is to spawn a thread for rendering. Each process is a thread by itself (talking about the main dispatching junction of your application). Separate application are separate processes and thus separate threads.
Therefore, leave your GUI in its own thread,
and have rendering in another.

Exact functions are available via SDK or Help. I am a Borland C++ Builder programmer and do not know by heart exact functions and their syntax.

Another suggestion. If you have real time rendering, you should put music and sound handling in another thread. Since you will most likely need >20 FPS for a smooth animation, that means also 20 responds to user events per second in-between two frames.
Music and sound require a bit greater precision, and is best to put their handles in another thread.

Hope this helps.