在Windows窗体加载与显示的事件 [英] Load vs. Shown events in Windows Forms

问题描述

但愿我只是失去了一些东西很明显，但我试图让我的头左右的负荷，在的 Windows窗体。

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 Windows Forms.

传统上，我只用负荷（或实际的OnLoad，因为我认为这是更清洁的覆盖方法，而不是依赖于设计师挂钩对自己的事件），因为这是在所有版本的.NET可用。在.NET 2.0中显示的事件进行了介绍。

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.

现在，如果你看一下MSDN文档中，这些描述（：，中显示：无论是第一次显示的形式出现。加载显示之前的一种形式，第一次发生。），它的声音的像应该发生Load事件，那么形式应该成为可见的，那么显示的事件应该发生;两者的结合，从而让你进行前后的形式是可见的一些任务。是有道理的，对不对？

Now, if you look at the descriptions for these in the MSDN documentation ("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?

然而，实验表明，已显示的事件总是发生的在的Load事件，每当我尝试它（无论之前发生的形式变得可见）。然而，当我围绕谷歌时，我发现了一个网页，讨论这些事件被触发的顺序，他们总是列出Load事件中被解雇第一。

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?)

（我现在的两个前做一些事情，并显示窗体后解决方案是使用的OnLoad为显示前的东西，开始一个短期的一次性的定时器，为后显示的东西。其中一期工程确定，可靠的，但它是一个有点难看，我希望有一个更清洁的解决方案，但它看起来像图中所示事件是吧。）

(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.)

推荐答案

避免使用的MessageBox.show（）调试此。该泵消息循环，干扰事件的正常流动。在加载的事件是由Windows发送WM_SHOWWINDOW消息，就在窗口变得可见触发。没有Windows通知为你的窗口现在已经尽显，所以WF设计师想出了一招，产生的所示的事件。他们使用Control.BeginInvoke（），确保OnShown（）方法，尽快称为程序进入再次空闲状态，重新进入消息循环。

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.

这招有很多其他用途，特别是当你不得不推迟了code。通过一个事件开始执行。然而，在你的情况下，它土崩瓦解，因为你使用的MessageBox.show（）。它的消息循环将调度的BeginInvoke（）注册的委托，导致显示的情况下运行的 的窗口显示之前。

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(). Its message loop dispatches the delegate registered with BeginInvoke(), causing the Shown event to run before the window is shown.

有很多其他的方式来获得超越MessageBox的诊断。 Debug.Print（）和Console.WriteLine（）是很方便的，它们的输出转到 Visual Studio的输出窗口< /一>而不对正常事件发射顺序的任何不利影响。一个简单的断点可以创造奇迹了。

There are lots of other ways to get diagnostics beyond MessageBox. Debug.Print() and Console.WriteLine() are handy, their output goes to the Visual Studio Output Window without having any detrimental effects on the normal event firing sequence. A simple breakpoint can do wonders too.

这篇关于在Windows窗体加载与显示的事件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！