I'm working on an existing C++.NET/OpenGL application that uses a timer to determine when to redraw the OpenGL stuff. I would like to convert this to the usual C++ game method, where you just redraw the screen every time you run through the message loop sort of like this: while(true) { TranslateMessage() DispatchMessage() RenderOpenGLStuff() } I'm just learning the .NET framework, but it looks like the entire message loop is hidden from the programmer. Is there some other way to achieve the equivalent functionality?

Thanks to both of you for your help. I posted a similar question on the MSDN .NET forums, and all I got was "you could edit your WndProc" (paraphrased).

Application.DoEvents() is bad. I read somewhere that it causes memory leaks or some other problem. There is some dll you can download that is a wrapper for standard c++ messaging. I think there is one in the DirectX SDK inside of one of the more complex examples. I'm thinking the LOD one, but I'm not sure.

Tom Miller discusses the use of the "OnApplicationIdle" function which, as I understand it, will run whenever there are no messages in the queue. I understand that this would be a rare case, but wouldn't it be possible to load up a program with a constant supply of messages so that the "OnApplicationIdle" function would never be called?

Wouldn't that be counterproductive? In order to stop ram from leaking, you make your processor constanly send messages to the application queue.

Can't you just do everything in OnPaint?

Bosh, you're right - it would be counterproductive. I'm not saying that you would want to do that. What I'm saying is that in plain old C++, you can build the message loop to ensure that the OpenGL stuff is updated constantly - even to the point that you can render between the processing of each message in the queue if you want to. What I have seen so far of the .NET framework indicates that it does not have that ability. Even if you use idle time to do your rendering, there is no way to know how many messages you have to process before you can get to that idle time. My understanding of .NET is pretty meager, though...I may be missing something obvious. My example of never having any idle time is extreme, I agree. I'm not sure what you mean by leaking ram, though.
By the way, I'm still looking into the DirectX SDK example you mentioned. That probably does what I just said .NET can't do ;-)

Tony, I don't have an issue with OnPaint except that it only gets called when Windows decides it is time to call it. I need the screen to be updating constantly, not just when it gets obscured by some other window (for example). I have to admit, though...my knowledge of OnPaint comes from the world of Win32. I don't know if it works the same in .NET or not.

Quote:Original post by DarthBill
Tony, I don't have an issue with OnPaint except that it only gets called when Windows decides it is time to call it. I need the screen to be updating constantly, not just when it gets obscured by some other window (for example). I have to admit, though...my knowledge of OnPaint comes from the world of Win32. I don't know if it works the same in .NET or not.

If you call Invalidate() at the end of OnPaint it will update it constantly.