How should the Form.Load event be used compared to its constructor method?

Question

When initializing properties of controls or other values related to a Form I have a tendency to switch back and forth between initializing the values in the Form's constructor and then later when the Form.Load event is evoked.

What is the generally accepted usage of a Forms constructor vs it's Form.Load event? With other classes I would do all initialization in the constructor. Yet in in VS when you double click on a Form it jumps you to an event handler for the Form.Load event not the constructor. This leads me to believe that it's preferable to do all the initialization after the Load event instead of the constructor.

Answer 1

When you double-click any control in the designer (including a form), you're jumped to the most common event handler for that control. That doesn't mean it's preferable to do anything there - just that someone's deemed it the most likely event handler.

A form's Load event typically happens after all of the controls have been created. The constructor happens beforehand. Depending on the logic you're implementing it might be beneficial to handle certain operations in one method or the other. For example, initializing many values is better done in a constructor: if the values effect the layout or content of the form, you might find that you're creating a "wasted" control hierarchy that's rebuilt when you change your values. Putting the initialization in the constructor might let the form build itself correctly first time - which is more performant and might avoid some errors.

Ultimately, both of those methods have their uses - look at what your code's doing and choose the one that's appropriate.

Answer 2

Yes, it is a wee bit sad that it works that way. It made a lot of sense at the time, now 10 years ago already. Windows Forms was targeted to be a replacement for VB6, the dominant point-and-click UI designer at the time. And Form_Load was important in VB6, that's where you customized the form view.

That wasn't really appropriate from the get-go, the Form class has a true-blooded constructor. And you can set control properties in the constructor before the actual native Window control gets created. There's a ton of code in WF to make that work. Code that the designer relies on, it sets these properties before the Load event fires. It is very efficient to do so, many controls get a lot slower when they need to be updated after their window is created. Like ListView and TreeView.

There are few reasons to not use the constructor yourself, like the designer does, especially since the C# IDE doesn't try to hide the constructor. Except one: you need the Load event when you write the kind of code that requires knowing the actual form size. That size isn't known until the window actually gets created, the Load event is the earliest after that. That ought to be rare.

And of course, if you do want to use Load then you override OnLoad instead of using the Load event. That would be another one.

Answer 3

I always use the constructor and almost never the form.Load event unless I can't get away without. The reason is because the constructor can receive parameters when the Load event can't really.

It is so much more useful