Where is the best place to do initialization in winform?

In the Load event or in the constructor after InitializeComponent ()?

or does it not matter at all?

+7
initialization winforms
source share
6 answers

The Form.Shown event is a good place for any initialization that can take more than one second. Form.Shown happens only once, right after the form first becomes visible to the user.

Obviously, if you have a lengthy initialization, you still need to provide some kind of visual feedback and possibly turn off sections of the form before completion. But if initialization is unavoidable, Form.Shown at least allows you to let the app know that it's not frozen, and give feedback on what it actually does.

Compared to Form.Load: from the point of view of users, your application will be perceived faster because your form is already displayed during initialization.

Compared to Form.Activated: you don’t have to worry about your initialization being done several times, because an activated event is fired every time your form is hidden / shown, minimized / maximized, etc.

Compared to the constructor: Like Form.Load, your form will not be visible until initialization is complete. In addition, you should be more careful about timing and sequence issues associated with controls that may not be fully initialized.

+5
source share

For heavier initialization, this is usually done in the load event. Constructors are commonly used to quickly and easily initialize fields. If you need to make a method call for an external dependency, for example, you must do this from the load.

+4
source share

Heavier initialization may also not be a good idea in a load event, as this can increase load times and can annoy the end user. I prefer to perform basic initialization (say, which takes <10 seconds) on the Load Form, and do the rest of the hard work after it is displayed to the user. So that the user can wait, a progress indicator may be displayed.

+3
source share

It depends on the type of initialization. A simple field initialization, for example, can be performed in the constructor, and this will save you from the need to connect an event, have an additional method, etc.

However, in some cases, the designer does not have the necessary information. For example, if you want to do different things depending on whether you are in development mode or execution mode (for example, in startup mode you connect to a data source, but in design mode you want to display sample data), then this should delay to until the structure is built, because the structure does not set the DesignMode until the object is created.

+2
source share

Maintaining material in the "Download" event will make exceptions when it is somewhat easier to read and IMHO is semantically cleaner. In practice, this does not make tons of difference.

+1
source share

Think about what happens if you run Show or ShowDialog twice for the same form. All things that cannot change between these two calls must be in the constructor; All initialization code, depending on the corresponding Show (Dialog) call, must be in the event handler that will be called for each of these calls. For example, the owner of the form is passed to ShowDialog , and not in the constructor, and may be different for two different calls to ShowDialog , so everything that depends on the owner should not be in the constructor.

0
source share

All Articles