Red cross on Windows

Hi All,

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.



Never heard of that red-x “feature” before, on which OS/GL implementation do you see this ?

Hi ZbuffeR,

Didn’t you ever seen this in a Windows OpenGL app:

It happpens on any Windows version we tested after a GL_ error…

By the way we are mainly interested to give the control back to windows painting in case of error and not to what the viewport displays.



Never seen that. Do you have a super simple repro case ?

It should be easy to assert for glGetError() and, if >0 , destroy GL context, etc ?

Just put a gl improper call within the glBegin() / glEnd() and you’ll get it.

Shall we simply destry the gl context? Afterwards we can use GDI to paint the window?



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.


I can only say that we use OpenGL in a Winform .NET app. Can this is be the reason?

Out of interest, what generally happens on a C++ Windows app?



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.

The app doesn’t die but that screen appears…

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…

In .NET red cross means control throw exception in paint.

Hi Yooyo,

This is not true - at least on my system. Probably it depends on the error type.



EDIT: for sure it happens also when you throw from a .NET window.

So, are those functions throwing exceptions when errors happen? If so, it looks like that may be your problem.

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.

Do you believe I can discover it adding a try/catch block into the OnPaint() method body?



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.