Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Reopening of bug 2506? GLControl inside a user control crashes during design time #49
I would like to fill a request to reopen bug 2506:
I've tried both compiling OpenTK 1.1-rc1 from sources and the current release (opentk-2014-01-15) to no avail.
My code compiles and runs fine, but visual studio 2012 crashes when I enter design mode for a form into which I put a custom user control that contains a docked GLControl.
Copied from link above, the workflow looks like this:
added a commit
Jan 18, 2014
This comment has been minimized.
This comment has been minimized.Show comment Hide comment
Thanks for the bug report. I wasn't able to reproduce the issue using these steps, but I have identified a possible regression caused by the external-context fixes in 1.1-beta4.
I have committed a potential fix in c2e3328, can you please try that and see if this resolves the issue?
You also need to make sure that you are not calling any OpenGL functions when running in design mode, as an OpenGL context will not generally be available inside the designer.
I tried the updated code without success. It seems that there is no way to properly detect whether we are in design mode or not. Try to attach the following paint callback to the glControl in the workflow stated above:
This should make it crash.
Just to add a bit more to that, I've also tried to test whether both the UserControl1's and the glControl's Load(object sender, EventArgs e) had been called by setting a boolean, something like:
but the designer (and VS2012) still crashes when given focus.
A quick check shows that it is not documented outside of bug reports / forum posts. We should update the documentation for the 1.1 release.
Design-time instability is a very common issue with custom controls, most WinForms developers will come across this at one point or another. In my experience, the check-for-design-mode-and-bail-out hack is the accepted solution.
That said, I'm open to suggestions for a less hacky approach.
Very old versions of OpenTK 0.3.x would create a real OpenGL context in design mode, which came a whole different set of issues (instability, memory exhaustion, outright IDE crashes.) Any OpenGL error during development could potentially bring down the whole IDE, making debugging a total nightmare.
Loading the OpenGL entry points with something harmless (a nop function) is theoretically possible, but extremely challenging to implement - and would still fail with functions returning data (e.g.