JTalton's picture

Converted project completely to OpenTK - Question on GameWindowExitException

I've converted my application over to completely use OpenTK. No more GTK, SDL, or true type font libraries. This will make deployment on different platforms that much easier and I am very happy about it.

I do have one question. GameWindowExitException gets thrown every time I debug the application and it gets so very annoying. Is there a way around this? I did find the following comments in a different post:

[GameWindowExitException]
It is the only way (I know of) to stop the main loop asynchronously.
I added this exception very reluctantly, but I really cannot see a better way.


Comments

Comment viewing options

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

Indeed, this should make distribution quite a bit easier.

It is actually possible to turn off this debugging "aid". Copying from the GameWindowExitException help message:

"This exception is a normal part of the GameWindow shutdown process and is completely harmless. While this warning will never be seen by end-users, Visual Studio reminds you that an exception is leaving your code unhandled, which can sometimes be a security breach.

You can disable this warning for this specific exception: select Debug->Exceptions from the menu bar and click ""Add"". Choose ""Common Language Runtime Exceptions"", type ""OpenTK.GameWindowExitException"" in the box below and click ""Ok"". Deselecting the ""User-unhandled"" checkbox from the newly created exception will disable this warning.

Alternatively, you can disable the ""Just my code"" debugging mode (""Tools->Options->Debugging->General"" and untick ""Enable Just my code (Managed only)"". This has the sideffect that it will allow you to step into OpenTK code if an error happens. Please, do this only if you are confident in your debugging skills."

The first method basically whitelists OpenTK.GameWindowExitException, so that the debugger doesn't break when it is encountered. The second method is much more invasive, as it affects debugging behavior globally. I'm listing it because this option can be very useful when developing applications with many reusable components, but it can be rather confusing if you are not aware of what you are getting into.

One last thing (which is of no consequence to this discussion, but might be interesting nonetheless) is that OpenTK.GameWindowExitException won't work when the event processing is moved to a different thread. It will likely be replaced by the builtin ThreadAbortException or something of that kind - obviously a change like this will need a lot of testing to make sure everything remains stable.