As you all know if an OpenGL error occurs - like GL_INVALID_VALUE - on a Windows rendering context the viewport displays a red cross (actually the two diagonals) on a white background indicating the failure.
I was wondering if a way to destroy the rendering context and give the ownership of the viewport surface back to Windows exists? This will allow us to display a more elegant error message.
Do you use the Microsoft OpenGL implementation? Because that’s no feature that “everyone knows of”. nVidia’s and ATI’s hardware accelerated implementations definitely don’t do that. I bet 99.99% people on this board heard about that the first time.
Out of interest, what generally happens on a C++ Windows app?
What the OpenGL spec says. That is, nothing. Commands that give rise to errors simply don’t execute. It’s not supposed to cause the application to die or go to a special screen.
I can confirm this happens only with .net (aka “managed”) applications. I’ve seen the red cross of death many times. No idea how to trap it and how to show something more elegant whatsoever…
I believe it is not related to gl error… it is related to error during processing WM_PAINT. In your case, control is host for gl context. Maybe your gl context is not valid and it throw exception.
Dunno… but this is dotnet question.
Anyway… I used .net few times before and I will never use it again, because it is slowest, buggiest package I ever used. it is nice if you use controls out-of-box. But if you try to do any extra work making controls used as you wish (like coloured list control…), then you will discover bug after bug.
From time to time I get a screen full of tiny, naked, fat people. This tends to occur at regular intervals of around 15 minutes but appears to be unrelated to any identifiable OpenGL error conditions.
Yooyo is correct, it means that an unhandled exception is being thrown in the Paint event. It has nothing explicit to do with OpenGL.
The OP didn’t mention which managed .net language (C#, C++, VB, etc.), or what type of control you are using (UserControl, Control, Panel, Picture, etc.).
Normally you should not have any exceptions occurring in the paint event unless there is a serious code design issue.
If you have to place any try/catch blocks then chances are something is wrong with the code design itself, in other words there is some code in the paint event that shouldn’t be there.
Normally the control will have OnPaintBackground overridden to prevent background painting, and Styles set for all painting in wmpaint.
Do not attempt any GDI drawing to the client (GetDC) or window (GetWindowDC) hDC or you will have issues on composited interfaces (Vista and W7).
Be sure to keep track of the control’s hDC and the hRC until you properly destroy the control and release all resources.
The Paint/OnPaint event handler should have a fail-safe check that tests whether the RC is valid (from the initial create rc call) and performs a GDI FillRectangle on the control client rectangle if the RC is not valid.
All GDI objects (brushes, pens, etc.) should always be correctly disposed, do not rely on the GC to handle this. If you are using C# then be sure to bracket them in a using() statement whenever possible. Do not maintain global GDI objects, always create and dispose in the paint handler.
On a final note, sorry I must disagree with Yooyo regarding using .net for application or OpenGL development. Managed .net works fine, it just requires some different programming tactics than Win32 and a good understanding of how .net works. My company is developing a retail application using OpenGL in .net and we are getting performance that is comparable to Win32 C++, but we are using a lot of specific programming techniques to achieve this. The application has over a dozen custom developed user interface controls including ‘subclassed’ .net controls without running into any ‘bugs’. However, each person may encounter their own specific problems depending on what they are developing.