650 Stimmen

Was sind in WPF die Unterschiede zwischen den Attributen x:Name und Name?

Manchmal scheint es, dass die Name y x:Name Attribute sind austauschbar.

Worin bestehen also die entscheidenden Unterschiede zwischen den beiden und wann ist es besser, die eine als die andere zu verwenden?

Gibt es irgendwelche Auswirkungen auf die Leistung oder den Speicher, wenn man sie falsch verwendet?

1 Stimmen

Die Antworten legen nahe, dass die Verwendung x:Name funktioniert die ganze Zeit über gut. Ich musste es nur ändern in Name Andernfalls konnte ich das Steuerelement in meinem .xaml.cs-Code nicht referenzieren, also gehe ich davon aus, dass es nicht mehr der Fall ist, dass es die ganze Zeit gut funktioniert.

521voto

chuckj Punkte 25340

In XAML gibt es eigentlich nur einen Namen, den x:Name . Ein Framework, wie z. B. WPF, kann optional eine seiner Eigenschaften der XAML-Eigenschaft x:Name durch die Verwendung der RuntimeNamePropertyAttribute auf die Klasse, die eine der Eigenschaften der Klasse als Zuordnung zum x:Name-Attribut von XAML bestimmt.

Der Grund dafür war, dass Frameworks, die bereits ein Konzept von "Name" zur Laufzeit haben, wie z. B. WPF, berücksichtigt werden sollten. In WPF, zum Beispiel, FrameworkElement führt eine Eigenschaft Name ein.

Im Allgemeinen muss eine Klasse nicht den Namen für x:Name brauchbar zu sein. Alle x:Name bedeutet für XAML, dass ein Feld generiert wird, um den Wert in der Klasse hinter dem Code zu speichern. Was die Laufzeit mit diesem Mapping macht, ist Framework-abhängig.

Warum gibt es also zwei Möglichkeiten, das Gleiche zu tun? Die einfache Antwort ist, dass es zwei Konzepte gibt, die auf eine Eigenschaft abgebildet werden. WPF möchte, dass der Name eines Elements zur Laufzeit erhalten bleibt (was u. a. über Bind möglich ist), und XAML muss wissen, welche Elemente über Felder im Code hinter der Klasse zugänglich sein sollen. WPF bindet diese beiden zusammen, indem es die Eigenschaft Name als Alias von x:Name markiert.

In Zukunft wird es in XAML mehr Verwendungsmöglichkeiten für x:Name geben, z. B. das Festlegen von Eigenschaften durch Verweis auf andere Objekte mit Namen, aber in 3.5 und früher wird es nur zum Erstellen von Feldern verwendet.

Ob Sie das eine oder das andere verwenden sollten, ist eigentlich eine Frage des Stils, nicht der Technik. Ich überlasse es anderen, eine Empfehlung auszusprechen.

Siehe auch AutomationProperties.Name VS x:Name AutomationProperties.Name wird von Zugänglichkeitswerkzeugen und einigen Testwerkzeugen verwendet.

108voto

Kenan E. K. Punkte 13604

Das ist nicht dasselbe.

x:Name ist ein Xaml-Konzept, das hauptsächlich zum Verweisen auf Elemente verwendet wird. Wenn Sie einem Element das x:Name xaml-Attribut geben, wird "der angegebene x:Name wird zum Namen eines Feldes, das im zugrunde liegenden Code erstellt wird, wenn xaml verarbeitet wird, und dieses Feld enthält einen Verweis auf das Objekt." ( MSDN ) Es handelt sich also um ein vom Designer erstelltes Feld, das standardmäßig internen Zugriff hat.

Name ist die vorhandene String-Eigenschaft einer FrameworkElement wie jede andere Eigenschaft eines wpf-Elements in Form eines xaml-Attributs aufgeführt.

Infolgedessen bedeutet dies auch, dass x:Name kann für eine größere Anzahl von Objekten verwendet werden. Dies ist eine Technik, die es ermöglicht, dass alles in xaml durch einen bestimmten Namen referenziert werden kann.

47voto

cgreeno Punkte 30732

X:Name und Name verweisen auf unterschiedliche Namensräume.

x:name ist ein Verweis auf den x-Namespace, der standardmäßig am Anfang der Xaml-Datei definiert ist.

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

Ich sage nur Name verwendet den Standard-Namensraum unten.

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

x:Name besagt, dass der Namespace verwendet werden soll, in dem die x alias. x ist der Standardwert, den die meisten Leute beibehalten, aber Sie können ihn nach Belieben ändern

xmlns:foo="http://schemas.microsoft.com/winfx/2006/xaml"

Ihre Referenz wäre also foo:name

Definieren und Verwenden von Namensräumen in WPF


OK, betrachten wir das Ganze einmal anders. Nehmen wir an, Sie ziehen eine Schaltfläche per Drag & Drop auf Ihre Xaml-Seite. Sie können dies auf 2 Arten referenzieren x:name y Name . Alle xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" et xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" sind Verweise auf mehrere Namespaces. Da xaml hält die Kontrolle Namespace (nicht 100%ig sicher) und Präsentation hält die FrameworkElement UND die Button-Klasse hat ein Vererbungsmuster von:

Button : ButtonBase
ButtonBase : ContentControl, ICommandSource
ContentControl : Control, IAddChild
Control : FrameworkElement
FrameworkElement : UIElement, IFrameworkInputElement, 
                    IInputElement, ISupportInitialize, IHaveResources

Wie nicht anders zu erwarten, hat alles, was von FrameworkElement erbt, Zugriff auf alle seine öffentlichen Attribute. Im Fall von Button erhält es also sein Attribut Name von FrameworkElement, ganz oben im Hierarchiebaum. Also können Sie sagen x:Name o Name und beide werden auf die Getter/Setter des FrameworkElements zugreifen.

MSDN-Referenz

WPF definiert ein CLR-Attribut, das von XAML-Prozessoren verwendet wird, um mehrere CLR-Namespaces auf einen einzigen XML-Namespace abzubilden. Die XmlnsDefinitionAttribut Attribut wird auf der Ebene der Baugruppe im Quellcode platziert, der die Baugruppe erzeugt. Der WPF-Assembly-Quellcode verwendet dieses Attribut, um die verschiedenen gemeinsamen Namespaces, wie System.Windows und System.Windows.Controls, auf den http://schemas.microsoft.com/winfx/2006/xaml/presentation Namensraum.

Die Attribute der Baugruppe sehen dann etwa so aus:

PresentationFramework.dll - XmlnsDefinitionAttribute:

[assembly: XmlnsDefinition("http://schemas.microsoft.com/winfx/2006/xaml/presentation", "System.Windows")]

[assembly: XmlnsDefinition("http://schemas.microsoft.com/winfx/2006/xaml/presentation", "System.Windows.Data")]

[assembly: XmlnsDefinition("http://schemas.microsoft.com/winfx/2006/xaml/presentation", "System.Windows.Navigation")]

[assembly: XmlnsDefinition("http://schemas.microsoft.com/winfx/2006/xaml/presentation", "System.Windows.Shapes")]

[assembly: XmlnsDefinition("http://schemas.microsoft.com/winfx/2006/xaml/presentation", "System.Windows.Documents")]

[assembly: XmlnsDefinition("http://schemas.microsoft.com/winfx/2006/xaml/presentation", "System.Windows.Controls")]

28voto

Steven Robbins Punkte 26083

Sie sind beide das Gleiche, viele Framework-Elemente stellen selbst eine Name-Eigenschaft zur Verfügung, aber für diejenigen, die das nicht tun, können Sie x:name verwenden - ich bleibe normalerweise bei x:name, weil es für alles funktioniert.

Steuerelemente können ihren Namen als Abhängigkeitseigenschaft offenlegen, wenn sie dies wünschen (weil sie diese Abhängigkeitseigenschaft intern verwenden müssen), oder sie können sich dagegen entscheiden.

Weitere Einzelheiten in msdn aquí y aquí :

Einige WPF-Anwendungen auf Framework-Ebene können möglicherweise auf die Verwendung des x:Name-Attributs vermeiden, da die Eigenschaft Name Abhängigkeitseigenschaft wie angegeben innerhalb des WPF-Namensraums für mehrere der wichtigen Basisklassen wie FrameworkElement/FrameworkContentElement den gleichen Zweck erfüllt. Es gibt noch einige gemeinsame XAML und Framework Szenarien, in denen der Codezugriff auf ein Element ohne Name-Eigenschaft notwendig ist, vor allem in bestimmten Animations- und Storyboard-Unterstützung Klassen. Zum Beispiel sollten Sie x:Name auf Zeitleisten und Transformationen, die in XAML erstellt wurden, angeben, wenn Sie beabsichtigen, sie im Code zu referenzieren.

Wenn Name als Eigenschaft verfügbar ist auf der Klasse verfügbar ist, können Name und x:Name austauschbar als Attribute verwendet werden, aber ein Fehler auftritt, wenn beide für dasselbe Element angegeben werden.

14voto

scott Punkte 147

X:Name kann Speicherprobleme verursachen, wenn Sie benutzerdefinierte Steuerelemente haben. Es wird ein Speicherplatz für den NameScope-Eintrag beibehalten.

Ich sage, verwenden Sie niemals x:Name, wenn Sie nicht müssen.

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X