views:

3795

answers:

6

Hopefully I'm just missing something obvious, but I'm trying to get my head around the differences between the Load and the Shown events in WinForms.

Traditionally I've only used Load (or actually OnLoad, since I think it's cleaner to override a method than to rely on the designer to hook up an event on yourself), since that is available in all versions of .NET. With .NET 2.0 the Shown event was introduced.

Now, if you look at the descriptions for these in the MSDN docs ("Load: Occurs before a form is displayed for the first time.", "Shown: Occurs whenever the form is first displayed.") it sounds like the Load event should occur, then the form should become visible, then the Shown event should occur; the combination of the two thereby letting you carry out some tasks both before and after the form is visible. Makes sense, right?

However, experimentation has shown that the Shown event invariably occurs before the Load event, whenever I try it (and both occur before the form becomes visible). And yet, when I google around whenever I discover a page that talks about the order these events are fired in, they always list the Load event being fired first.

Am I just going crazy, or have I missed something? (And if they do occur at about the same time, then why was the Shown event added in the first place?)

(My current solution for doing something both before and after showing the form is to use OnLoad for the "before showing" stuff and start a short-duration one-shot timer for the "after showing" stuff. Which works ok and reliably, but it's a bit ugly and I was hoping there was a cleaner solution. But it looks like the Shown event isn't it.)

A: 

one thing I know for sure is the shown event is executed after everything on the InitializeComponent is done and the form is showing up and it's in the shown that you should put the code that move object on the form based on the location of other object

do a quick test with an empty project:

Public Class Form1

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
    MsgBox("load") 'form is still visible = false
End Sub

Private Sub Form1_Shown(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Shown
    MsgBox("shown") ' form is now visible = true
End Sub
End Class
Fredou
A: 

I just checked and load fires before Shown as it should.

There's obviously something wrong in your approach.

Cyril Gupta
A: 

Ok, I think I've worked out what's really going on now, and where my confusion was coming from (although not why it behaves that way). It looks like the Shown event actually occurs inside the Load event.

Given this code:

 protected override OnLoad(EventArgs e)
{
    MessageBox.Show("Enter Load");
    base.OnLoad(e);
    MessageBox.Show("Exit Load");
}

protected override OnShown(EventArgs e)
{
    MessageBox.Show("Enter Shown");
    base.OnShown(e);
    MessageBox.Show("Exit Shown");
}

then the messages are shown in this order:

  1. Enter Load
  2. Enter Shown
  3. Exit Shown
  4. Exit Load

The Visible property is True in all four cases yet in none of these cases is the form actually visible on screen (painted).

The really weird thing though is that if I comment out the "Exit Load" messagebox then the form does appear on screen before the "Enter Shown" message appears. It seems to be code executed after the base OnLoad call that it's really objecting to somehow.

Miral
For perfect experiment try to log into file not to use messagebox, use streamwiter or File class
Ahmed Said
A: 

The Shown event occured after the load event, the main difference is not in the visibility but in state of the form (width,hieght,..etc). I will give you an example to clarify if we create a form with default size 100,200 and set the windowstate = Maximized in the load event the size will be 100,200 but in shown event the size will be your screen size

Ahmed Said
+8  A: 

Avoid using MessageBox.Show() to debug this. It pumps a message loop, disturbing the normal flow of events. The Load event is triggered by Windows sending the WM_SHOWWINDOW message, just before the window becomes visible. There is no Windows notification for "your window is now fully shown", so the WF designers came up with a trick to generate the Shown event. They use Control.BeginInvoke(), ensuring the OnShown() method gets called as soon as the program goes idle again and re-enters the message loop.

This trick has lots of other uses, particularly when you have to delay the execution of code started by an event. However, in your case it falls apart because you use MessageBox.Show(). It's message loop dispatches the delegate registered with BeginInvoke(), causing the Shown event to run before the window is shown.

There are lots of other ways to get diagnostics beyond MessageBox. Console.WriteLine() is handy, its output goes to the Visual Studio Output window. A simple breakpoint can do wonders too.

Hans Passant
Makes sense. Although the original question was triggered by something else occurring out of sequence that didn't involve MessageBoxes -- but it probably did include pumping messages anyway. The key seems to be to ensure no other code runs after base.OnLoad.
Miral
A: 

Here's the sequence of event I traced. May this will help others to decide how they would like to call or set their custom event handling

Events traced

Form - Client Size Changed : 8/14/2010 10:40:28 AM Form - Control Added - button1 : 8/14/2010 10:40:29 AM Form - Constructor : 8/14/2010 10:40:29 AM Form - Handle Created : 8/14/2010 10:40:29 AM Form - Invalidated : 8/14/2010 10:40:29 AM Form - Form Load event : 8/14/2010 10:40:29 AM Form - Loaded : 8/14/2010 10:40:29 AM Form - Create Control : 8/14/2010 10:40:29 AM Form - OnActivated : 8/14/2010 10:40:29 AM Form - Shown : 8/14/2010 10:40:29 AM Form - OnPaint : 8/14/2010 10:40:29 AM Form - Invalidated : 8/14/2010 10:40:29 AM Form - OnPaint : 8/14/2010 10:40:29 AM

Krishnan