Perché eseguire codice nel metodo chiamato da XAML Window.Loaded?

Question

Ho visto un esempio di codice che crea un metodo Window_Loaded() quale è invocato il XAML di "Window 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> 

Ma nel codice dietro, il codice ha lavorato sia nel costruttore e il metodo 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? 
     } 
    } 
} 

Ci sono dei vantaggi nel fare ciò?

Esiste un "Ciclo di caricamento della finestra" come in ASP.NET che è utile conoscere, ovvero metodi come PreRender(), PostRender(), ecc.?

Answer 1

Sì, esiste un ciclo di vita simile per i controlli WPF, proprio come in ASP.NET. Il ciclo di vita dei controlli WPF è più semplice, in quanto fondamentalmente si tratta di un evento inizializzato, caricato e scaricato (in questo ordine). Vedere:

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

e Mike Hillberg ha un eccellente articolo che dimostra la differenza tra gli eventi initalized e caricati:

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

Answer 2

Ottimi collegamenti, Razzie.

Edward - troverai che la distinzione più interessante è che il Contractor è sempre il primo metodo chiamato su Window/Page/UserControl e non puoi contare su tutti i DependencyProperties che sono stati inizializzati ai loro valori finali. Inoltre, è sconsigliato chiamare qualsiasi metodo virtuale dal tuo constructructor.

L'evento Loaded, al contrario, viene generalmente chiamato alla fine dei processi di inizializzazione ... cioè, quando Window/Page/UserControl è stato completamente caricato in un elemento WPF ElementTree. Dall'interno dell'evento caricato, puoi tranquillamente chiamare qualsiasi metodo e modificare qualsiasi DepenencyProperty senza il rischio di risultati imprevisti.

Un motivo piacevole (che sto attualmente utilizzando nel mio progetto) consiste nell'inizializzare le proprietà di dipendenza personalizzate nell'evento Loaded se non sono state modificate durante l'inizializzazione. Per i controlli, questo modello consente di evitare di inizializzare proprietà "costose" (come DependencyProperty che è ObservableCollection) se vengono sovrascritte (ad esempio da una proprietà Binding dal codice chiamante).

Risposta semplice: utilizzare l'evento Loaded se non si è sicuri su come sovraccaricare in sicurezza il costruttore.