Dans WPF, quelles sont les différences entre les attributs x: Name et Name?

Le titre dit tout. Parfois, il semble que les attributs Nameet x:Namesoient interchangeables.

Alors, quelles sont les différences définitives entre eux, et quand est-il préférable d'utiliser l'un sur l'autre?

Y a-t-il des implications en termes de performances ou de mémoire dans leur mauvaise utilisation?

Il n'y a vraiment qu'un seul nom en XAML, le x:Name. Un framework, tel que WPF, peut éventuellement mapper l'une de ses propriétés aux XAML x:Nameen utilisant RuntimeNamePropertyAttributela classe sur qui désigne l'une des propriétés des classes comme mappant à l'attribut x: Name de XAML.

La raison pour laquelle cela a été fait était de permettre des frameworks qui ont déjà un concept de "Nom" au moment de l'exécution, comme WPF. Dans WPF, par exemple, FrameworkElementintroduit une propriété Name.

En général, une classe n'a pas besoin de stocker le nom pour x:Nameêtre utilisable. Tout x:Namemoyen pour XAML est de générer un champ pour stocker la valeur dans le code derrière la classe. Ce que le runtime fait avec ce mappage dépend du framework.

Alors, pourquoi y a-t-il deux façons de faire la même chose? La réponse simple est qu'il existe deux concepts mappés sur une propriété. WPF veut que le nom d'un élément soit conservé au moment de l'exécution (qui est utilisable entre autres par Bind) et XAML doit savoir quels éléments vous voulez être accessibles par les champs dans le code derrière la classe. WPF relie ces deux éléments en marquant la propriété Name comme un alias de x: Name.

À l'avenir, XAML aura plus d'utilisations pour x: Name, comme vous permettant de définir des propriétés en faisant référence à d'autres objets par leur nom, mais dans les versions 3.5 et antérieures, il n'est utilisé que pour créer des champs.

Que vous deviez utiliser l'un ou l'autre est vraiment une question de style, pas une question technique. Je laisserai cela à d'autres pour une recommandation.

Voir aussi AutomationProperties.Name VS x: Name , AutomationProperties.Name est utilisé par les outils d'accessibilité et certains outils de test.

Ce n'est pas la même chose.

x:Nameest un concept xaml, utilisé principalement pour référencer des éléments. Lorsque vous attribuez à un élément l'attribut x: Name xaml, "le spécifié x:Namedevient le nom d'un champ qui est créé dans le code sous-jacent lorsque xaml est traité, et ce champ contient une référence à l'objet". ( MSDN ) Il s'agit donc d'un champ généré par le concepteur, qui a un accès interne par défaut.

Nameest la propriété de chaîne existante de a FrameworkElement, répertoriée comme toute autre propriété d'élément wpf sous la forme d'un attribut xaml.

En conséquence, cela signifie également qu'il x:Namepeut être utilisé sur une plus large gamme d'objets. Il s'agit d'une technique pour permettre à tout élément de xaml d'être référencé par un nom donné.

x: Nom et Nom font référence à des espaces de noms différents.

x: nom est une référence à l'espace de noms x défini par défaut en haut du fichier Xaml.

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

Dire simplement que Name utilise l'espace de noms par défaut ci-dessous.

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

x: Nom signifie utiliser l'espace de noms qui a le x alias . x est la valeur par défaut et la plupart des gens la quittent, mais vous pouvez la changer en ce que vous voulez

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

donc votre référence serait foo: nom

Définir et utiliser des espaces de noms dans WPF

OK, regardons cela différemment. Supposons que vous glissiez et déposiez un bouton sur votre page Xaml. Vous pouvez référencer ce 2 façons x: nom et nom . Tous les xmlns = "http://schemas.microsoft.com/winfx/2006/xaml/presentation" et xmlns: x = "http://schemas.microsoft.com/winfx/2006/xaml" sont des références à plusieurs espaces de noms . Étant donné que xaml contient l' espace de noms Control (pas 100% sur cela) et la présentation contient FrameworkElement ET la classe Button a un modèle d'héritage de:

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

Donc, comme on pourrait s'y attendre, tout ce qui hérite de FrameworkElement aurait accès à tous ses attributs publics. ainsi, dans le cas de Button, il obtient son attribut Name de FrameworkElement, tout en haut de l'arborescence de la hiérarchie. Ainsi , vous pouvez dire x: Nom ou nom et ils seront à la fois être l' accès au getter / setter de la FrameworkElement.

Référence MSDN

WPF définit un attribut CLR utilisé par les processeurs XAML afin de mapper plusieurs espaces de noms CLR à un seul espace de noms XML. L' attribut XmlnsDefinitionAttribute est placé au niveau de l'assembly dans le code source qui produit l'assembly. Le code source de l'assembly WPF utilise cet attribut pour mapper les divers espaces de noms courants, tels que System.Windows et System.Windows.Controls, à la espace de noms http://schemas.microsoft.com/winfx/2006/xaml/presentation .

Ainsi, les attributs d'assemblage ressembleront à:

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")]  

Ils sont tous les deux la même chose, de nombreux éléments du framework exposent eux-mêmes une propriété de nom, mais pour ceux qui ne le font pas, vous pouvez utiliser x: name - je reste généralement avec x: name car il fonctionne pour tout.

Les contrôles peuvent s'exposer eux-mêmes comme propriété de dépendance s'ils le souhaitent (car ils doivent utiliser cette propriété de dépendance en interne), ou s'ils peuvent choisir de ne pas le faire.

Plus de détails dans msdn ici et ici :

Certaines applications au niveau du framework WPF peuvent éviter toute utilisation de l'attribut x: Name, car la propriété de dépendance Name spécifiée dans l'espace de noms WPF pour plusieurs des classes de base importantes telles que FrameworkElement / FrameworkContentElement remplit ce même objectif. Il existe encore quelques scénarios XAML et framework courants où l'accès au code d'un élément sans propriété Name est nécessaire, notamment dans certaines classes de support d'animation et de storyboard. Par exemple, vous devez spécifier x: Name sur les lignes de temps et les transformations créées en XAML, si vous avez l'intention de les référencer à partir du code.

Si Name est disponible en tant que propriété sur la classe, Name et x: Name peuvent être utilisés de manière interchangeable en tant qu'attributs, mais une erreur se produira si les deux sont spécifiés sur le même élément.

X: le nom peut provoquer des problèmes de mémoire si vous disposez de contrôles personnalisés. Il conservera un emplacement mémoire pour l'entrée NameScope.

Je dis de ne jamais utiliser x: Name sauf si vous le devez.

La seule différence est que si vous utilisez des contrôles utilisateur dans un contrôle du même assemblage, le nom n'identifiera pas votre contrôle et vous obtiendrez une erreur «Utiliser x: nom pour les contrôles du même assemblage». Donc x: Name est la version WPF des contrôles de dénomination dans WPF. Le nom est simplement utilisé comme Winform Legacy. Ils voulaient différencier la dénomination des contrôles dans WPF et winforms car ils utilisent des attributs dans Xaml pour identifier les contrôles des autres assemblys qu'ils utilisaient x: pour les noms de contrôle.

Gardez juste à l'esprit que ne mettez pas de nom pour un contrôle juste pour le garder car il réside dans la mémoire comme un blanc et il vous avertira que Name a été appliqué pour un contrôle mais il n'est jamais utilisé.

Nom :

1. peut être utilisé uniquement pour les descendants de FrameworkElement et FrameworkContentElement;
2. peut être défini à partir de code-behind via SetValue () et de type propriété.

x: Nom :

1. peut être utilisé pour presque tous les éléments XAML;
2. ne peut PAS être défini à partir de code-behind via SetValue (); il ne peut être défini qu'en utilisant la syntaxe d'attribut sur les objets car il s'agit d'une directive.

L'utilisation des deux directives dans XAML pour un FrameworkElement ou FrameworkContentElement provoquera une exception: si le XAML est compilé avec le balisage, l'exception se produira lors de la compilation du balisage, sinon elle se produira lors du chargement.

x:Name signifie: créer un champ dans le code derrière pour contenir une référence à cet objet.

Name signifie: définir la propriété name de cet objet.

J'utilise toujours la variante x: Name. Je ne sais pas si cela affecte les performances, je trouve cela plus facile pour la raison suivante. Si vous avez vos propres contrôles utilisateur qui résident dans un autre assembly, la propriété "Name" ne suffira pas toujours. Cela permet de coller plus facilement la propriété x: Name.

Ce n'est pas un élément WPF mais un élément XML standard et BtBh y a répondu correctement, x fait référence à l'espace de noms par défaut. En XML, lorsque vous ne préfixez pas un élément / attribut avec un espace de noms, cela suppose que vous voulez l'espace de noms par défaut. Donc, taper Namen'est rien de plus qu'une courte main pour x:Name. Plus de détails sur les espaces de noms XML peuvent être trouvés dans le texte du lien

L'une des réponses est que x: name doit être utilisé dans différents langages de programme tels que c # et name doit être utilisé pour le framework. Honnêtement, c'est ce que cela me semble.

Le x: Name spécifié devient le nom d'un champ qui est créé dans le code sous-jacent lorsque XAML est traité, et ce champ contient une référence à l'objet. Dans Silverlight, à l'aide de l'API managée, le processus de création de ce champ est effectué par les étapes cibles MSBuild, qui sont également chargées de joindre les classes partielles d'un fichier XAML et son code-behind. Ce comportement n'est pas nécessairement spécifié en langage XAML; c'est l'implémentation particulière que Silverlight applique pour utiliser x: Name dans ses modèles de programmation et d'application.

En savoir plus sur MSDN ...

Lorsque vous déclarez un élément Button en XAML, vous faites référence à une classe définie dans le temps d'exécution de Windows appelée Button.

Le bouton a de nombreux attributs tels que l'arrière-plan, le texte, la marge, ..... et un attribut appelé Nom.

Maintenant, lorsque vous déclarez un bouton en XAML, c'est comme créer un objet anonyme qui se trouvait avoir un attribut appelé Nom.

En général, vous ne pouvez pas faire référence à un objet anonyme, mais dans le cadre WPF, le processeur XAML vous permet de faire référence à cet objet par la valeur que vous avez donnée à l'attribut Name.

Jusqu'ici tout va bien.

Une autre façon de créer un objet est de créer un objet nommé au lieu d'un objet anonyme. Dans ce cas, l'espace de noms XAML a un attribut pour un objet appelé Nom (et comme il se trouve dans l'espace de noms XAML, vous avez donc X :) que vous pouvez définir afin que vous puissiez identifier votre objet et y faire référence.

Conclusion:

Le nom est un attribut d'un objet spécifique, mais X: le nom est un attribut de cet objet (il existe une classe qui définit un objet général).

Ma recherche est x:Nameaussi globale variable. Cependant, Namecomme variable locale . Cela signifie-t-il que x: Name vous pouvez l'appeler n'importe où dans votre fichier XAML, mais le nom ne l'est pas.
Exemple:

<StackPanel>
<TextBlock Text="{Binding Path=Content, ElementName=btn}" />
<Button Content="Example" Name="btn" />
</StackPanel>
<TextBlock Text="{Binding Path=Content, ElementName=btn}" />

Vous ne pouvez pas la Bindingpropriété Contentde Buttonavec le nom est "btn" car il en dehorsStackPanel