If you have used the Windows Forms designer in Visual Studio 2005 enough, chances are you may have occasionally seen a white error screen instead of the design time form. This screen, fondly referred to as WSoD in our team, shows up when error(s) are encountered in the process of loading the designer. Now, if you have used Visual Studio 2002/2003, you may recollect that in the face of errors, the designer would usually continue the load and quietly display the errors in the tasklist. That was much less intrusive and did not require the developer to drop whatever they were doing and fix the errors. Why then did we take this seemingly retrograde step back into the Windows 95 era?
There is a very good reason for that. If an error is encountered while loading the designer and you ignore it and make modifications to the design time form, there is inevitably one result – data loss. This is because the next time the designer flushes, it will wipe InitializeComponent() clean and serialize out code for the current state of components in the designer (this is how the designer always works). If there were lines of code in there that it failed to parse during the load, at this point they will be lost. This could mean property sets or even whole components ‘disappear’ from the designer.
It is to prevent this inadvertant data loss that we introduced the WSoD in VS 2005. The WSoD makes it very obvious to the user that there were errors, and does not allow modifications to be made to the designer till they are resolved. Now, unlike its blue counterpart, the WSoD actually contains information useful to the user. It shows a list of errors that were encountered along with stack traces and very often, the line of code in InitializeComponent() that is responsible for each error. Equipped with this information, the developer should be able to open the code behind file (which is now thankfully in a separate partial class, distinct from user code) and fix up the lines that caused the problem.
Now, clearly, not everyone is a huge fan of this idea. Developers don’t like being blocked from making progress this way. For example, let’s say you have a DataGridView and some other controls on your form referencing a DataSet in the project. If you delete the DataSet when you have the form designer window open, you will likely see a WSoD. This can be frustrating – why wasn’t VS clever enough to auto-correct the problem for me?
Well, the problem is: what is the right solution?
Should it delete all the controls referencing the dataset automatically? What if the developer wanted them to remain there so they could set them up with a new dataset?
Should it keep the controls, but ignore the error and continue to load? Well, if the developer misses the warnings in the task list, all of a sudden, they might end up with controls in a bad state and lose some data.
So you see, there is no good ‘automagic’ solution. We thought it best to leave the developer in control of the situation and decide the best way to fix the issue. Essentially, we weighed user-friendlyness with data loss and ruled in favor of preventing data loss as much as possible. I don’t know about you, but I would prefer to spend a few minutes fixing stuff up rather than inadvertantly losing hours of hard work with the next flush.
P.S.> If you have never heard of the BSoD (I am sure there are plenty of you that haven’t :-)), here is a good description.