548 votes

Dans WPF, quelles sont les différences entre le x:Nom et les attributs de Nom?

Le titre dit tout. Parfois, il semble que l' Name et x:Name attributs sont interchangeables.

Donc, ce sont en définitive les différences entre eux, et quand est-il préférable d'utiliser l'un plutôt que l'autre?

Existe-il des performances ou de la mémoire des implications de leur utilisation dans le mauvais sens?

MODIFIER les Réponses jusqu'à présent suggèrent que l'utilisation d' x:Name tous les temps, fonctionne très bien, mais je veux toujours savoir quelle est la différence. Microsoft a mis ces deux attributs dans la première version de WPF, donc il doit y avoir une explication logique.

460voto

chuckj Points 7975

Il n'y a vraiment qu'un seul nom en XAML, x:Name. Un cadre, comme WPF, peut éventuellement carte de l'une de ses propriétés de XAML x:Name par l'aide de la RuntimeNamePropertyAttribute sur la catégorie qui désigne l'une des classes de propriétés que la cartographie de l'attribut x:Name de XAML.

La raison de ce qui a été fait, c'était pour permettre de cadres qui ont déjà une notion de "Nom" au moment de l'exécution, comme WPF. Dans WPF, par exemple, FrameworkElement introduit un Nom de propriété.

En général, une classe n'a pas besoin de stocker le nom d' x:Name pour être utilisable. Tous x:Name moyen de XAML est de générer un champ pour stocker la valeur dans le code de la classe. Ce que le moteur d'exécution ne avec que la cartographie est un framework dépendante.

Alors, pourquoi il y a deux façons de faire la même chose? La réponse est simple parce qu'il y a deux concepts sont mappées sur une propriété. WPF veut que le nom d'un élément conservé au moment de l'exécution (qui est utilisable par le biais de Lier, parmi d'autres choses) et XAML a besoin de savoir quels sont les éléments que vous voulez être accessibles par des champs dans le code-behind de la classe. WPF relie ces deux ensemble en marquant le Nom de la propriété comme un alias de x:Name.

Dans l'avenir, XAML aura plus d'utilisations pour les x:Nom, comme vous permettant de définir les propriétés par référence à d'autres objets par leur nom, mais en 3.5 et avant, il est seulement utilisé pour créer des champs.

Si vous devez utiliser l'un ou l'autre est vraiment un style de question, pas de technique. Je vais laisser cela à d'autres, pour une recommandation.

Voir aussi AutomationProperties.Nom VS x:Nom, AutomationProperties.Le nom est utilisé par les outils d'accessibilité et des outils de tests.

85voto

Kenan E. K. Points 8497

Ils ne sont pas la même chose.

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

Name est la chaîne existante de la propriété d'un FrameworkElement, répertorié comme tout autre wpf élément de propriété sous la forme d'un attribut xaml.

En conséquence, cela signifie également x:Name peut être utilisé sur une large gamme d'objets. C'est une technique pour activer quelque chose dans le code xaml pour être référencé par un nom donné.

36voto

cgreeno Points 17379

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

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

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

Juste dire le Nom utilise la valeur par défaut ci-dessous de l'espace de noms.

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

x:Nom , c'est dire l'utilisation de l'espace de noms a la x alias. x est la valeur par défaut et la plupart des gens laisser, mais vous pouvez changer 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

EDIT:

OK permet de regarder ce d'une manière différente. Dites que vous faites glisser et déposez un bouton sur votre page Xaml. Vous pouvez faire référence à ce 2 manières 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. Depuis xaml détient le Contrôle de l'espace de noms(pas 100% sur) et présentation détient le FrameworkElement ET le Bouton de classe a un modèle héréditaire de:

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

De sorte que l'on pourrait s'attendre à quelque chose qui hérite de FrameworkElement aurait accès à tous ses publics attributs. ainsi, dans le cas de Bouton, il est l'attribut Nom de FrameworkElement, au sommet de la hiérarchie de l'arbre. Donc vous pouvez dire x:Name ou Nom et ils seront tous deux accès à la lecture/définition de la FrameworkElement.

Référence MSDN

WPF définit un CLR attribut qui est consommée par le XAML processeurs afin de mapper plusieurs CLR espaces de noms pour un seul espace de noms XML. Le XmlnsDefinitionAttribute attribut est placé au niveau de l'assemblage dans le code source qui produit l'assemblée. WPF assemblée de code source utilise cet attribut à la carte les différents espaces de noms communs, tels que le Système.Windows et le Système.De Windows.Les contrôles de, à la http://schemas.microsoft.com/winfx/2006/xaml/presentation espace de noms.

De sorte que l'assemblée des attributs de ressembler à quelque chose comme:

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

20voto

Steven Robbins Points 18791

Ils sont tous les deux la même chose, beaucoup d'éléments du cadre d'exposer un nom de propriété eux-mêmes, mais pour ceux qui n'en ont pas, vous pouvez utiliser x:nom - j'ai l'habitude de simplement coller avec x:nom parce que ça marche pour tout.

Les contrôles peuvent exposer nom eux-mêmes en tant que DP s'ils le désirent (parce qu'ils ont besoin d'utiliser que DP interne), ou ils peuvent choisir de ne pas.

Plus de détails dans msdn ici et ici:

Certains framework WPF au niveau des applications peut-être en mesure d'éviter toute utilisation de l' x:Nom de l'attribut, parce que le Nom la dépendance de la propriété comme indiqué au sein de l'espace de noms WPF pour plusieurs de l'importance des classes de base tels que FrameworkElement/FrameworkContentElement répond à ce même but. Il y a encore quelques communes XAML et le cadre les scénarios où le code d'accès à un élément avec aucun Nom de la propriété est nécessaire, notamment dans certains l'animation et le storyboard de soutien des classes. Par exemple, vous devez spécifier x:Nom sur les échéances et transforme créée dans le code XAML, si vous l'intention de les référencer à partir du code.

Si le Nom est disponible à la propriété la classe, le Nom et x:Nom peut être utilisé de façon interchangeable, comme les attributs, mais un erreur se produit si les deux sont spécifié sur le même élément.

10voto

scott Points 29

X:Nom peut provoquer des problèmes de mémoire si vous avez des commandes personnalisées. Il gardera un emplacement de mémoire pour la portée de nom de l'entrée.

Je dis ne jamais utiliser de x:Nom, sauf si vous avez.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by: