Freigeben über

x:Name-Direktive

  • Artikel

Identifiziert XAML-definierte Elemente in einem XAML-NameScope eindeutig. XAML-NameScopes und ihre Eindeutigkeitsmodelle können auf die instanziierten Objekte angewendet werden, wenn Frameworks APIs bereitstellen oder Verhaltensweisen implementieren, die zur Laufzeit auf das XAML-erstellte Objektdiagramm zugreifen.

XAML-Attributverwendung

<object x:Name="XAMLNameValue".../>

XAML-Werte

Wert Beschreibung
XAMLNameValue Eine Zeichenfolge, die den Einschränkungen der XamlName Grammarentspricht.

Bemerkungen

Nachdem x:Name auf das zugrunde gelegte Programmiermodell eines Frameworks angewendet wurde, entspricht der Name der Variablen, die einen Objektverweis oder eine Instanz enthält, wie sie von einem Konstruktor zurückgegeben wird.

Der Wert einer x:Name direktiven Verwendung muss innerhalb eines XAML-NameScopes eindeutig sein. Standardmäßig wird der primäre XAML-NameScope bei Verwendung der .NET XAML Services-API im XAML-Stammelement einer einzelnen XAML-Produktion definiert und umfasst die Elemente, die in dieser XAML-Produktion enthalten sind. Zusätzliche diskrete XAML-NameScopes, die in einer einzelnen XAML-Produktion auftreten können, können von Frameworks definiert werden, um bestimmte Szenarien zu behandeln. In WPF werden beispielsweise neue XAML-NameScopes definiert und von jeder Vorlage erstellt, die auch in dieser XAML-Produktion definiert ist. Weitere Informationen zu XAML-NameScopes (geschrieben für WPF, aber relevant für viele XAML-NameScope-Konzepte), finden Sie unter WPF XAML NameScopes.

Im Allgemeinen sollten x:Name nicht in Situationen angewendet werden, die auch x:Keyverwenden. XAML-Implementierungen durch bestimmte vorhandene Frameworks haben Ersetzungskonzepte zwischen x:Key und x:Nameeingeführt, dies ist jedoch keine empfohlene Vorgehensweise. .NET XAML Services unterstützt solche Ersetzungskonzepte bei der Behandlung von Namens-/Schlüsselinformationen wie INameScope oder DictionaryKeyPropertyAttributenicht.

Regeln für die Zulassung von x:Name sowie die Durchsetzung der Eindeutigkeit von Namen werden potenziell durch spezifische Implementierungsframeworks definiert. Um jedoch mit .NET XAML Services verwendbar zu sein, sollten die Frameworkdefinitionen der XAML-NameScope-Eindeutigkeit mit der Definition von INameScope Informationen in dieser Dokumentation konsistent sein und dieselben Regeln verwenden, in denen die Informationen angewendet werden. Die WPF-Implementierung (Windows Presentation Foundation) teilt z. B. verschiedene Markupelemente in separate NameScope Bereiche auf, z. B. Ressourcenwörterbücher, die logische Struktur, die vom XAML-Code auf Seitenebene, Vorlagen und anderen verzögerten Inhalten erstellt wurde, und erzwingt dann die Eindeutigkeit von XAML-Namen innerhalb dieser XAML-NameScopes.

Für benutzerdefinierte Typen, die XAML-Objektautoren von .NET XAML Services verwenden, kann eine Eigenschaft, die x:Name für einen Typ zugeordnet ist, eingerichtet oder geändert werden. Sie definieren dieses Verhalten, indem Sie auf den Namen der Eigenschaft verweisen, die dem RuntimeNamePropertyAttribute im Typdefinitionscode zugeordnet werden soll. RuntimeNamePropertyAttribute ist ein Attribut auf Typebene.

Using.NET XAML-Dienste kann die Sicherungslogik für die XAML-NameScope-Unterstützung auf frameworkneutrale Weise definiert werden, indem die INameScope-Schnittstelle implementiert wird.

WPF-Verwendungshinweise

Unter der Standardbuildkonfiguration für eine WPF-Anwendung, die XAML, partielle Klassen und CodeBehind verwendet, wird die angegebene x:Name zum Namen eines Felds, das im zugrunde liegenden Code erstellt wird, wenn XAML von einer Markupkompilierungsbuildaufgabe verarbeitet wird und dieses Feld einen Verweis auf das Objekt enthält. Standardmäßig ist das erstellte Feld intern. Sie können den Feldzugriff ändern, indem Sie das x:FieldModifier-Attributangeben. In WPF und Silverlight definiert und benennt die Markupkompilierung das Feld in einer partiellen Klasse, der Wert ist jedoch anfänglich leer. Anschließend wird eine generierte Methode namens InitializeComponent aus dem Klassenkonstruktor aufgerufen. InitializeComponent besteht aus FindName Aufrufen unter Verwendung der einzelnen x:Name Werte, die im XAML-definierten Teil der partiellen Klasse als Eingabezeichenfolgen vorhanden sind. Die Rückgabewerte werden dann dem Verweis auf like-named field zugewiesen, um die Feldwerte mit Objekten auszufüllen, die aus der XAML-Analyse erstellt wurden. Die Ausführung von InitializeComponent ermöglichen es, mithilfe des x:Name/Feldnamens direkt auf das Laufzeitobjektdiagramm zu verweisen, anstatt FindName explizit aufrufen zu müssen, wenn Sie einen Verweis auf ein XAML-definiertes Objekt benötigen.

Für eine WPF-Anwendung, die die Microsoft Visual Basic-Ziele verwendet und XAML-Dateien mit Page Buildaktion enthält, wird während der Kompilierung eine separate Verweiseigenschaft erstellt, die das schlüsselwort WithEvents allen Elementen mit einem x:Namehinzufügt, um Handles Syntax für Ereignishandlerdelegatten zu unterstützen. Diese Eigenschaft ist immer öffentlich. Weitere Informationen finden Sie unter Visual Basic- und WPF-Ereignisbehandlung.

x:Name wird vom WPF-XAML-Prozessor verwendet, um einen Namen zur Ladezeit in einem XAML-NameScope zu registrieren, auch wenn die Seite nicht durch Buildaktionen kompiliert wird (z. B. loses XAML eines Ressourcenwörterbuchs). Ein Grund für dieses Verhalten ist, dass die x:Name möglicherweise für ElementName Bindung benötigt wird. Ausführliche Informationen finden Sie unter Data Binding Overview.

Wie bereits erwähnt, sollten x:Name (oder Name) nicht in Situationen angewendet werden, in denen auch x:Keyverwendet wird. Die WPF-ResourceDictionary weist ein spezielles Verhalten auf, sich selbst als XAML-NameScope zu definieren, aber nicht implementierte oder NULL-Werte für INameScope-APIs zurückzugeben, um dieses Verhalten zu erzwingen. Wenn der WPF-XAML-Parser auf Name oder x:Name in einer xaml-definierten ResourceDictionarytrifft, wird der Name keinem XAML-NameScope hinzugefügt. Beim Versuch, diesen Namen aus einem beliebigen XAML-NameScope zu finden, und die FindName Methoden geben keine gültigen Ergebnisse zurück.

x:Name und Name

Viele WPF-Anwendungsszenarien können die Verwendung des x:Name-Attributs vermeiden, da die Name Abhängigkeitseigenschaft, wie im Standard-XAML-Namespace angegeben, für mehrere der wichtigen Basisklassen wie FrameworkElement und FrameworkContentElement diesen Zweck erfüllt. Es gibt noch einige gängige XAML- und WPF-Szenarien, in denen der Codezugriff auf ein Element ohne Name Eigenschaft auf Frameworkebene wichtig ist. Bestimmte Animations- und Storyboardunterstützungsklassen unterstützen z. B. keine Name Eigenschaft, sie müssen jedoch häufig im Code referenziert werden, um die Animation zu steuern. Sie sollten x:Name als Attribut für Zeitachsen und Transformationen angeben, die in XAML erstellt werden, wenn Sie später im Code darauf verweisen möchten.

Wenn Name als Eigenschaft für die Klasse verfügbar ist, können Name und x:Name austauschbar als Attribute verwendet werden, aber eine Analyseausnahme führt dazu, wenn beide für dasselbe Element angegeben sind. Wenn das XAML-Markup kompiliert wird, tritt die Ausnahme bei der Markupkompilierung auf, andernfalls tritt sie beim Laden auf.

Name können mithilfe der XAML-Attributsyntax und im Code mit SetValuefestgelegt werden; Beachten Sie jedoch, dass das Festlegen der Name-Eigenschaft im Code den repräsentativen Feldverweis innerhalb des XAML-NameScopes in den meisten Fällen nicht erstellt, in denen der XAML-Code bereits geladen wurde. Anstatt Name im Code festzulegen, verwenden Sie NameScope Methoden aus Code für den entsprechenden NameScope.

Name kann auch mithilfe der Eigenschaftselementsyntax mit innerem Text festgelegt werden, das ist jedoch ungewöhnlich. Im Gegensatz dazu kann x:Name nicht in der XAML-Eigenschaftselementsyntax oder im Code mit SetValuefestgelegt werden; sie kann nur mithilfe der Attributsyntax für Objekte festgelegt werden, da es sich um eine Direktive handelt.

Silverlight-Verwendungshinweise

x:Name für Silverlight wird separat dokumentiert. Weitere Informationen finden Sie unter XAML-Namespace (x:) Language Features (Silverlight).

Siehe auch