terryhau's picture

GLControl inside a user control crashes during design time

Project:The Open Toolkit library
Version:1.1-2014-01-02
Component:Code
Category:bug report
Priority:normal
Assigned:the Fiddler.
Status:closed
Description

When you place a GLControl directly on to a form, it works fine.
However if you put a GLControl on to a user control and put that user control on to the form,
the GLControl creates a rendering context during design time and often it fails, causing crashes or errors.
It appears to be a problem or "feature" of the WinForms designer. Nested controls are alive during design time.
If you have code that draws to the GLControl, you will see it being drawn during design time.
http://support.microsoft.com/kb/839202

From what I've read, the way around it is to use if(LicenseManager.UsageMode == LicenseUsageMode.Designtime) instead of if(DesignMode)
but this test only works in the control's constructor. However it can be evaluated in the constructor and stored for later use.
I think if all the if(DesignMode) checks in GLControl.cs are changed to use a more reliable check, it should fix the problem.
http://dotnetfacts.blogspot.com/2009/01/identifying-run-time-and-design-...
http://stackoverflow.com/questions/34664/designmode-with-controls

It's easy to reproduce but I will upload a sample project if I can figure out how.
1. Create new WinForms project
2. Add new user control called UserControl1
3. Drop a GLControl on to the user control
4. Rebuild project
5. Drop UserControl1 on to main form
6. GLControl should crash


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
terryhau's picture

#1

Title:GLControl inside a user control crashes» GLControl inside a user control crashes during design time
sjoerd222's picture

#2

You can avoid this problem by using if (!DesignMode) in your controlls Load and Paint function.

See example.

private void MyControl_Load(object sender, EventArgs e)
        {
            if (!DesignMode)
            {
                try
                {
                    MakeCurrent();
                    Whatever.Init();
                }
                catch(Exception ex)
                {
                    throw new ApplicationException(ex.Message);
                }
            }
        }
private void MyControl_Paint(object sender, PaintEventArgs e)
        {
            if (!DesignMode)
            {
                MakeCurrent();
                Whatever.Render();
            }
        }
the Fiddler's picture

#3

Assigned to:Anonymous» the Fiddler.
Status:open» in progress (review)

SVN trunk r3068 now contains a potential fix for this issue. Can you please check that it no longer occurs?

sjoerd222's picture

#4

For me only System.Diagnostics.Process.GetCurrentProcess().ProcessName == "devenv" worked.

In trunk revision 3069 not fixed!

kanato's picture

#6

Do not rely on the DesignMode property - it will return false when your usercontrol is placed into a Form. The correct way to check for design-time is to use the static LicenseManager.UsageMode property:

if (LicenseManager.UsageMode == LicenseUsageMode.Designtime) return;

Checking process name probably isn't a good idea either, since another IDE (such as SharpDevelop) will have a different process name.

tomxp411's picture

#7

This still happens with VS2010.

Here's the message I get:

The control OpenTK.GLControl has thrown an unhandled exception in the designer and has been disabled.
Exception:
Exception of type 'OpenTK.Graphics.GraphicsContextException' was thrown.
Stack trace:
at OpenTK.GLControl.OnHandleCreated(EventArgs e)

There's no way to intercept this and prevent the error at design time. This happens even with NO rendering code active.

The workaround is to add the control at runtime. I placed all the logic in an Init() method which is called from the main form.

ganaware's picture

#8

With the latest release ( opentk-2010-10-06.exe ),
the problem happened on VSExpress 2013 too.

But with the latest nightly build (opentk-2013-11-12.zip ),
there is no problem.

Use it .

the Fiddler's picture

#9

Version:1.0-2010-10-06» 1.1-dev
Status:in progress (review)» fixed

Thanks for testing, this will be included in the upcoming beta release.

the Fiddler's picture

#10

Version:1.1-dev» 1.1-2014-01-02
Status:fixed» closed

Closing bugs fixed in OpenTK 1.1.

If this is still an issue, please file a new bug report at https://github.com/opentk/opentk/issues