Bei der Untersuchung eines Problems mit der Anwendung, an der ich gerade arbeite, bin ich auf ein Verhalten gestoßen, das ich nicht ganz verstehe. Es scheint, dass das System, wenn Sie eine TextBox (zum Beispiel) mit gebundener Text-Eigenschaft haben, einen weiteren Layout-Durchlauf benötigt, als wenn Sie einen statischen Text haben.
Könnte bitte jemand erklären, warum dieser Extra-Pass passiert? Legt der Motor die ungebundene Kontrolle zuerst an, bindet sie dann und legt sie dann erneut?
Um das zu testen, habe ich einen solchen Testfall gebaut:
Ich habe eine von TextBox geerbte Klasse deklariert (damit ich ArrangeOverride außer Kraft setzen kann):
%Vor%Dann habe ich eine Instanz dieses Textfelds in einem Fenster platziert:
%Vor%Und etwas Code für das zu testende Fenster hinzugefügt:
%Vor%Wenn ich das jetzt ausführe, bekomme ich diese Ausgabe:
%Vor%Aber wenn ich die Text-Eigenschaft ändere, um so gebunden zu werden:
%Vor%Ich bekomme das in der Ausgabe:
%Vor%Beachten Sie das zusätzliche Paar TextBox.Arrange und Window.Arrange. Warum ist dieser Extra-Pass notwendig?
Liegt der Motor ungebunden? Kontrolle zuerst dann bindet es und dann legt es noch einmal?
Dies könnte tatsächlich der Fall sein - Die WPF-Datenbindung basiert auf Abhängigkeitseigenschaften , die sich auf den WPF-Layoutprozess auswirken, siehe Überlegungen zur Layout-Leistung :
Abhängigkeitseigenschaften, deren Werte Ursache für das Layout-System sein initialisiert sind mit öffentlich gekennzeichnet Flaggen. AffectsMeasure und AffectsArrange bietet nützliche Hinweise zu dem sich der Eigenschaftswert ändert Erzwinge eine rekursive Aktualisierung durch das Layout System. Im Allgemeinen jede Eigenschaft, die kann die Größe eines Elements beeinflussen Bounding Box sollte die setzen AffectsMeasure -Flag auf true. Für mehr Informationen finden Sie unter Abhängigkeit Eigenschaftenübersicht .
Und speziell zu Ihrer Frage finden Sie dieses Zitat von Optimierung der Leistung: Layout und Design :
Der Layout-Durchlaufprozess wird erneut aufgerufen, wenn eine der folgenden Aktionen ausgeführt wird:
- [...]
- Wenn eine Änderung am Wert einer abhängigen Eigenschaft auftritt markiert mit Metadaten, die die Maßnahme beeinflussen oder Pässe anordnen.
Folglich könnte ich mir vorstellen, dass der anfängliche Layout-Durchlauf nicht anders als der Anwendungsfall einer späteren Änderung des gebundenen Werts betrachtet wurde, was das Verhalten, das Sie erleiden, erklären würde. Obwohl diese noch eine verpasste Möglichkeit zur Optimierung der Startup-Erfahrung darstellt, gelten die üblichen Optimierungsvorbehalte: keine Optimierung ohne Messung - z. Diese vermeintliche Redundanz (wenn überhaupt technisch vermeidbar) kann keine messbaren Auswirkungen haben, weil das Fenster / Steuerelement noch nicht gezeigt wurde usw.
Debugging:
Um Drews Vorschläge für eine Debugging-Hilfe hinzuzufügen gibt es eine neue dedizierte Debughilfe, die sich auf die in .NET Framework 3.5 eingeführte Bindung bezieht, siehe PresentationTraceSources.TraceLevel - Beispiel:
Dafür gibt es einige Einschränkungen. Lesen Sie unbedingt Abschnitt Hinweise in PresentationTraceSources Class .
Nicht direkt eine Antwort, aber was passiert, wenn Sie der Bindung einen Konverter hinzufügen, der nur eine Nachricht ausgibt, die Ihnen anzeigt, an welcher Stelle die Bindung ausgewertet wird?
%Vor%