Silverlight 控件生命周期 2

FrameworkElement.Loaded 事件

http://msdn.microsoft.com/zh-cn/library/system.windows.frameworkelement.loaded(v=vs.95).aspx 

 

此事件使用 RoutedEventHandler 委托类型，但是此事件不路由（而许多 Silverlight 输入事件都路由）。但是，对象树的 XAML 加载的本质决定了通常将要显示的模式在表面上类似冒泡路由事件模式：在加载某一对象之前必须对该对象设置所有属性。嵌套层次最深的对象（例如没有子对象的对象）在所有其 XAML 属性具有值之后最先载入。对于具有子对象的对象，其中一个属性就是用于包含子对象的属性。因此，加载对象树时，将按向上方向的顺序引发 Loaded 事件。 但是，此序列实际上是每个按该顺序引发其自己的 Loaded 事件的对象。不同的 Loaded 事件不共享事件数据；这些事件都是单独事件，每个事件都由不同对象源引发。

上述说明中有例外：Loaded 事件按相反的树顺序引发。因此，不要完全依赖于 Loaded 顺序来提供应用程序逻辑。下面是 Loaded 顺序可以改变的一些示例情况：

• 大多数情况下，从应用的控件模板或数据模板创建的对象是引发 Loaded 的最后对象。但是，如果特定控件在初始化时使用 ApplyTemplate 来强制加载早期模板，顺序原则可能不同。

• 由于模板应用程序和 ItemsControl 中项的数据表示规则，有时这些项将在其父级 ItemsControl 引发 Loaded 之后，并在主（非模板化）对象树的其他分支引发 Loaded 后才引发其父级引发的事件。

Silverlight 不具有与 WPF 事件 Initialized 等效的事件。

根据布局调整大小通常不会重新加载对象。请参见 SizeChanged。

已加载和控件对象生存期

Silverlight 中 Loaded 事件的执行时间不同于 WPF 中 FrameworkElement.Loaded 事件的执行时间。具体地说，WPF Loaded 事件在应用模板之后发生。在 Silverlight 中，Loaded 事件并不一定在应用模板之后发生。如果对以下相对常见的控件方案使用 Loaded 事件，这可能是一个问题：您希望检查可视化树，以获得作为其他对象的源的值或更改模板化组合（您只有在运行时才能从中知道新值）中的值。在这种情况下，调用 SilverlightVisualTreeHelper 方法来检查模板内容的可视化树可能不起作用（如果直接从 Loaded 处理程序进行调用）。

有几种方法可以解决此问题。每种方法都有各自的优点和可能的限制：

• 如果您从现有控件派生，而不为 Loaded 添加处理，您可以重写 OnApplyTemplate。OnApplyTemplate 是专门针对以下情况的回调：您具有来自模板的树，并且现在希望检查或调整可视对象。一个限制是如果仅仅将一个现有的控件用作应用程序的一部分，则无法更改有关 OnApplyTemplate 的任何内容。

• 您仍可以继续使用 Loaded。但是，作为 Loaded 处理程序中的第一个调用，是对该控件调用 ApplyTemplate。ApplyTemplate 是一个同步方法，因此一旦进行该调用并且该调用返回后，便会立即显示模板创建的可视化树。在这种情况下调用 ApplyTemplate 不会在 Silverlight 运行时的对应部分上重复此工作。一个限制是您关注的元素确实必须是 Control 派生类。

• 可以对 LayoutUpdated（而非 Loaded）进行处理。LayoutUpdated 是启用 Silverlight UI 中的控件的序列中的最后一个“对象生存期”事件。LayoutUpdated 的主要限制是初始化可能不是引发 LayoutUpdated 的唯一时间。此外，还会为布局更改中涉及的对象引发 LayoutUpdated。例如，布局中的对等可能已更改其大小。就可视化树而言，即使对等对象可能仅更改了几个属性值但并未更改树结构，正在处理 LayoutUpdated 的对象的可视化树也可能完全不会发生更改。因此，您可能必须应用自己的逻辑以确定 LayoutUpdated 事件是否确实表示您需要检查或重新检查可视化树。

请注意，有一些处理 Loaded 的方案不受模板应用程序执行时间问题的影响。例如，即使尚不能访问模板部件，仍可为引发 Loaded 的对象添加事件处理程序或设置属性。例如，您可以在代码中创建对象并在此时将其添加到内容属性或内容集合中，或添加您选择不在初始 XAML 中挂钩的输入类型事件处理程序。