Warum zum ausführen von code in der Methode namens XAML Fenster.Geladen?

Sah ich ein code-Beispiel, erstellt eine Methode Window_Loaded() das von XAML "Fenster Geladen" 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>

Aber in der code-behind, der code war in beiden der Konstruktor und die Window_Loaded() Methode:

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

Gibt es irgendwelche Vorteile, dies zu tun?

Gibt es ein "Fenster" Load Cycle", wie in ASP.NET Los hier, dass ist hilfreich zu wissen, über, D. H. Methoden wie PreRender(), PostRender() usw?

InformationsquelleAutor Edward Tanguay | 2009-03-16
  1. 12

    Ja, es gibt einen ähnlichen Lebenszyklus für WPF-Steuerelemente nur wie in ASP.NET. Der Lebenszyklus von WPF-Steuerelementen wird einfacher, obwohl, wie es im wesentlichen bestehend aus einem initialisiert, geladen und entladen-Ereignis (in dieser Reihenfolge). Siehe:

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

    und Mike Hillberg hat einen ausgezeichneten Artikel veranschaulicht den Unterschied zwischen den zuerst entsprechend formatiert und geladen Ereignisse:

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

    • Mike Hillberg schreibt in seinem blog "wenn Sie nicht sicher sind, welche Veranstaltung zu verwenden, und Sie nicht möchten, Lesen Sie mehr, verwenden Sie das Loaded-Ereignis". Ausgezeichnet, ich fühle mich ein wenig überlastet mit WPF im moment und das ist alles was ich brauche, um zu wissen, für jetzt. Danke für den link!
    • WPF kann sich ein wenig überwältigend. Ich persönlich fühle mich wie ich habe nur gesehen die Spitze des Eisbergs.
    InformationsquelleAutor Razzie
  2. 3

    Hervorragende links, die goldene Himbeere.

    Edward - Sie werden feststellen, dass die meisten interressant Unterscheidung ist, dass der Contructor wie immer die erste Methode aufgerufen, Ihre Fenster/Seite/UserControl und Sie können sich nicht darauf verlassen, dass alle DependencyProperties wurde initialisiert, um Ihre letzten Werte. Es ist auch schlecht beraten zu nennen, alle virtuellen Methoden innerhalb Ihrer construtructor.

    Das Loaded-Ereignis, durch Kontrast, ist in der Regel genannt werden am Ende der Initialisierung-Prozesse... das ist - wenn die Fenster/Seite/UserControl vollständig geladen wurde in einem WPF-ElementTree. In Ihrem loaded-Ereignis, können Sie getrost aufrufen von Methoden, und ändern Sie alle DepenencyProperty ohne Risiko unerwarteter Ergebnisse.

    Einem schönen Muster (die, die ich derzeit benutze in meinem Projekt) ist die Initialisierung benutzerdefinierte abhängigkeitseigenschaften in das Loaded-Ereignis wenn Sie noch nicht geändert wurde während der Initialisierung. Für Steuerelemente, die dieses Muster können Sie vermeiden, initialisieren "teurer" Eigenschaften (wie ein DependencyProperty, die eine ObservableCollection), wenn Sie überschrieben wird (z.B. durch eine Eigenschaft Bindung von der Landesvorwahl).

    Einfache Antwort: Verwenden Sie die Geladenen Ereignis, wenn Sie sich nicht sicher sind, wie sicher überladen Sie den Konstruktor.

    • schöne Zusammenfassung 🙂
    InformationsquelleAutor Mark
Schreibe einen Kommentar