为什么要在 XAML Window.Loaded 调用的方法中运行代码？
我看到一个代码示例，它创建了一个由 XAML 的“Window Loaded”事件调用的方法 Window_Loaded()：
<Window x:Class="TestModuleLoader.Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Window1" Height="300" Width="300" Loaded="Window_Loaded">
<Grid>
...
</Grid>
</Window>
但在后面的代码中，代码在构造函数和 Window_Loaded( ) 方法：
using System.Windows;
namespace TestModuleLoader
{
public partial class Window1 : Window
{
public Window1()
{
InitializeComponent();
}
private void Window_Loaded(object sender, RoutedEventArgs e)
{
//what advantages do I have running code here?
}
}
}
这样做有什么好处吗？
是否有像 ASP.NET 中那样的“窗口加载周期”有助于了解，即诸如 PreRender()、PostRender() 等方法？
I saw a code example that creates a method Window_Loaded() which is called by XAML's "Window Loaded" event:
<Window x:Class="TestModuleLoader.Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Window1" Height="300" Width="300" Loaded="Window_Loaded">
<Grid>
...
</Grid>
</Window>
But in the code behind, the code worked in both the constructor and the Window_Loaded() method:
using System.Windows;
namespace TestModuleLoader
{
public partial class Window1 : Window
{
public Window1()
{
InitializeComponent();
}
private void Window_Loaded(object sender, RoutedEventArgs e)
{
//what advantages do I have running code here?
}
}
}
Are there any advantages to doing this?
Is there a "Window Load Cycle" as in ASP.NET going on here that is helpful to know about, i.e. methods such as PreRender(), PostRender(), etc?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，WPF 控件也有类似的生命周期，就像在 ASP.NET 中一样。 不过，WPF 控件的生命周期更简单，因为它基本上由初始化、加载和卸载事件（按此顺序）组成。 请参阅：
http://msdn.microsoft.com/en-us/library/ms754221 .aspx
和 Mike Hillberg 有一篇出色的文章演示了 initalized 事件和已加载事件之间的区别：
http://blogs.msdn.com/mikehillberg/archive/2006/09/19/LoadedVsInitialized.aspx
Yes, there is a similar life cycle for WPF controls, just like in ASP.NET. The life cycle of WPF controls is simpler though, as it basically consits of an initialized, loaded, and unloaded event (in that order). See:
http://msdn.microsoft.com/en-us/library/ms754221.aspx
and Mike Hillberg has an excellent article demonstrating the difference between the initalized and loaded events:
http://blogs.msdn.com/mikehillberg/archive/2006/09/19/LoadedVsInitialized.aspx
很棒的链接，拉齐。
Edward - 您会发现最有趣的区别是构造函数始终是在 Window/Page/UserControl 上调用的第一个方法，并且您不能指望所有 DependencyProperties 都已初始化为其最终值。 另外，不建议从构造函数中调用任何虚拟方法。
相比之下，Loaded 事件通常在初始化过程结束时调用...即，当 Window/Page/UserControl 已完全加载到 WPF ElementTree 中时。 在加载的事件中，您可以放心地调用任何方法并修改任何 DepenencyProperty，而不会出现意外结果的风险。
一个很好的模式（我目前在我的项目中使用）是在 Loaded 事件中初始化自定义依赖属性如果它们在初始化期间没有被修改。 对于控件，此模式允许您避免初始化“昂贵”的属性（例如作为 ObservableCollection 的 DependencyProperty），如果它们被覆盖（即通过调用代码中的属性 Binding）。
简单答案：如果您不确定如何安全地重载构造函数，请使用 Loaded 事件。
Excellent links, Razzie.
Edward - you'll find that the most interresting distinction is that the Contructor as always the first method called on your Window/Page/UserControl and you can't count on all DependencyProperties having been initialized to their final values. Also, it's ill advised to call any virtual methods from within your construtructor.
The Loaded event, by contrast, is generally called at the end of the initialization processes... that is - when the Window/Page/UserControl has been fully loaded into a WPF ElementTree. From within your loaded event, you can confidently call any methods and modify any DepenencyProperty without risk of unexpected results.
A nice pattern (which I'm currently using in my project) is to initialize custom dependency properties in the Loaded event if they haven't been modified during initialization. For controls, this pattern allows you to avoid initializing "expensive" properties (like a DependencyProperty which is an ObservableCollection) if they are being overwritten (i.e. by a property Binding from the calling code).
Simple answer: Use the Loaded event if you're not sure about how to safely overload the constructor.