.net - code - xaml doc




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

Le titre dit tout. Parfois, il semble que les attributs Name et x:Name sont 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 de performance ou de mémoire à les utiliser dans le mauvais sens?


Ce n'est pas la même chose.

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

Name est la propriété de chaîne existante d'un objet 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 aussi que x:Name peut être utilisé sur une plus large gamme d'objets. C'est une technique pour permettre à n'importe quoi dans xaml d'être référencé par un nom donné.


Ce n'est pas un élément WPF mais un élément XML standard et BtBh 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, il suppose que vous voulez l'espace de noms par défaut. Donc taper simplement Name n'est rien de plus qu'une petite main pour x:Name . Plus de détails sur les espaces de noms XML peuvent être trouvés au lien texte


Ils sont tous les deux la même chose, beaucoup d'éléments de framework exposent eux-mêmes une propriété name, mais pour ceux qui ne le font pas, vous pouvez utiliser x: name - je m'en tiens à x: name parce que ça marche pour tout.

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

Plus de détails dans msdn here et here :

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 satisfait le même objectif. Il existe encore quelques scénarios XAML et framework communs où l'accès au code à un élément sans propriété Name est nécessaire, notamment dans certaines classes d'animation et de support de storyboard. Par exemple, vous devez spécifier x: Nom sur les timelines 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.


J'utilise toujours la variante x: Name. Je n'ai aucune idée si cela affecte les performances, je trouve juste plus facile pour la raison suivante. Si vous avez vos propres contrôles utilisateur qui résident dans un autre assemblage, la propriété "Nom" ne suffira pas toujours. Cela facilite le collage de la propriété x: Name.


La seule différence est que si vous utilisez les contrôles utilisateur dans un contrôle de Same Assembly, Name n'identifiera pas votre contrôle et vous obtiendrez une erreur "Utiliser x: Nom pour les contrôles dans le même assemblage". So x: Name est le versionnement WPF des contrôles de nommage dans WPF. Le nom est simplement utilisé comme héritage Winform. Ils voulaient différencier le nommage des contrôles dans WPF et winforms car ils utilisent des attributs dans Xaml pour identifier les contrôles d'autres assemblys qu'ils utilisaient x: for Names of control.

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


Le x: Name spécifié devient le nom d'un champ créé dans le code sous-jacent lors du traitement de XAML et ce champ contient une référence à l'objet. Dans Silverlight, en utilisant l'API gérée, le processus de création de ce champ est effectué par les étapes cibles MSBuild, qui sont également responsables de la jonction des classes partielles pour 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 ...


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

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


x: Nom et Nom référencent des espaces de noms différents.

x: name 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"

Juste en disant que Name utilise l'espace de noms ci-dessous.

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

x: Le nom indique utiliser l'espace de noms qui a l'alias x . x est la valeur par défaut et la plupart des gens la quittent mais vous pouvez la changer pour 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 les espaces de noms dans WPF

OK laisse regarder cela différemment. Disons que vous faites glisser et déposez un bouton sur votre page Xaml. Vous pouvez référencer ces 2 façons x: nom et nom . Tous 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 . Puisque xaml contient l'espace de noms Control (pas 100% sur cela) et que la présentation contient la classe FrameworkElement AND 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

Comme on peut 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 à partir de FrameworkElement, tout en haut de l'arborescence de la hiérarchie. Vous pouvez donc dire x: Nom ou Nom et ils accéderont tous les deux au getter / setter à partir de FrameworkElement.

Référence MSDN

WPF définit un attribut CLR qui est consommé 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 différents espaces de noms communs, tels que System.Windows et System.Windows.Controls, à l'espace de noms http://schemas.microsoft.com/winfx/2006/xaml/presentation .

Ainsi, les attributs d'assemblage ressembleront à ceci:

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

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 propriété-like.

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'à l'aide de la syntaxe d'attribut sur les objets car il s'agit d'une directive.

L'utilisation des deux directives en XAML pour un FrameworkElement ou FrameworkContentElement entraînera une exception: si le code XAML est compilé, l'exception se produira sur la compilation de balisage, sinon elle se produira au chargement.







name-attribute