¿Por qué ejecutar código en el método llamado por XAML Window.Loaded?

Question

vi un ejemplo de código que crea un método Window_Loaded() que es llamada por XAML de "Ventana Loaded" evento:

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

Pero en el código subyacente, el código trabajado tanto en el constructor y el método 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? 
     } 
    } 
} 

¿Hay alguna ventaja al hacer esto?

¿Hay un "Ciclo de carga de la ventana" como en ASP.NET pasando aquí que es útil conocer, es decir, métodos como PreRender(), PostRender(), etc.?

Answer 1

Sí, hay un ciclo de vida similar para los controles WPF, al igual que en ASP.NET. Sin embargo, el ciclo de vida de los controles WPF es más simple, ya que básicamente se trata de un evento inicializado, cargado y descargado (en ese orden). Ver:

http://msdn.microsoft.com/en-us/library/ms754221.aspx

y Mike Hillberg tiene un excelente artículo que demuestra la diferencia entre los eventos initalized y cargados:

http://blogs.msdn.com/mikehillberg/archive/2006/09/19/LoadedVsInitialized.aspx

Answer 2

excelentes enlaces, Razzie.

Edward - encontrará que la distinción más interesante es que el Contructor como siempre el primer método llamó a su Ventana/Página/UserControl y no puede contar con que todas las DependencyProperties se hayan inicializado a sus valores finales. Además, no es aconsejable llamar a ningún método virtual desde tu construtructor.

El evento Cargado, por el contrario, generalmente se llama al final de los procesos de inicialización ... es decir, cuando Window/Page/UserControl se ha cargado por completo en WPF ElementTree. Desde dentro de su evento cargado, puede llamar con confianza a cualquier método y modificar cualquier DepenencyProperty sin riesgo de resultados inesperados.

Un buen patrón (que estoy usando actualmente en mi proyecto) es inicializar las propiedades de dependencia personalizadas en el evento Loaded si no se han modificado durante la inicialización. Para los controles, este patrón le permite evitar la inicialización de propiedades "costosas" (como DependencyProperty que es una ObservableCollection) si se sobrescriben (es decir, mediante un enlace de propiedad desde el código de llamada).

Respuesta simple: Utilice el evento Cargado si no está seguro de cómo sobrecargar el constructor de forma segura.