Page rating	73% for 29 votes	Useless Brilliant

Introduction

If you only read the first line of this. DO NOT use Application.EnableVisualStyles(). However if you feel you must. Call Application.DoEvents() directly after it.

This is not an article on how to do stuff. This one is about what not to do and what caused an SEHException to appear after moving a splitter or closing a ShowDialog. What made this more frustrating was that it only occurred if the dialog was opened from the tool bar after the tool bar had been reconfigured via a socket request. I pored 4 solid days of my life into this.

In the end I resorted to (do not try this at home);

• Not calling the tool bar button event handler directly. Instead starting a 1ms timer to call the tool bar handler. This solver 75% of the problems
• Removing all splitters form dialogs created from the tool bar
• Wrapping every ShowDialog call in an Exception handler
• All I had to do was delete the line Application.EnableVisualStyles()

Other peoples comments

The rest of this article was blatantly stolen from Jeff Key's site. It is an excellent account of the problem.

EnableVisualStyles: Part of Evil Axis?

If you're using v1.1 of the Framework and encounter an SEHException and have no idea what's causing it, check to see if you called Application.EnableVisualStyles().¢ÎApparently that is the source for a number of problems that appear as SEHExceptions. My problem in particular was happening when I tried to show a form with ShowDialog().¢ÎIf I used Show() instead, no problems.¢ÎAll of my other forms had no problems with ShowDialog, yet this one would crash the app. After a bit of Googling, it appears that this error can come up almost anywhere, so keep this in mind as it's almost always the solution. Interestingly, using a manifest file to get the same results does NOT< cause the app to crash.¢ÎGo figure.