InitializeComponent, Abstract Base Forms and Visual Studio Design Behavior

It is interesting to know how the Designers works in Visual Studio when one is designing a component, control or form (controls and forms by the way are special kind of components with visual representation at the document surface).  Knowing such kind of information can be crucial for a Windows Form Developer.

The InitializeComponent perhaps is the most popular code block generated by Visual Studio.  When you create a subclass of System.Windows.Forms.Form, an InitializeComponent method is created by default which is called from your Form’s constructor.  It contains all the property settings (non-default) for every component/control that you used.  Let’s consider the scenario where one is designing a form with a number of controls in it.

During design-time, the constructor of the form being designed is never executed (VS could not create an instance of it since it is currently under construction).  Even the additional properties that you add will only be available in the property grid for the subclass of that form.  But how come the control apperances follow that of the settings in the InitializeComponent generated code if the constructor is never executed at design-time?

Visual Studio’s behavior when one is designing a form is to create an instance of your component’s immediate base class (in this case the .NET Form), and then parse the InitializeComponent section (deserializes it) and apply the changes to that instance.  You can test this by deleting the call to the InitializeComponent method in your Form subclass’ constructor.  This is also the reason why one cannot have the base form to be declared as abstract during development since VS will try to instantiate it when one will be designing a subclass of it.

References:
Brian Pepin’s Blog