No WPF, quais são as diferenças entre os atributos x: Name e Name?

O título diz tudo. Às vezes, parece que os atributos Name e x:Name são intercambiáveis.

Então, quais são as diferenças definitivas entre eles, e quando é preferível usar um sobre o outro?

Há algum desempenho ou implicações de memory para usá-los da maneira errada?

Existe realmente apenas um nome em XAML, o x:Name . Uma estrutura, como o WPF, pode mapear opcionalmente uma de suas propriedades para x:Name do XAML usando o RuntimeNamePropertyAttribute na class que designa uma das propriedades de classs como mapeamento para o atributo x: Name de XAML.

A razão pela qual isso foi feito foi permitir estruturas que já tenham um conceito de “Nome” em tempo de execução, como o WPF. No WPF, por exemplo, o FrameworkElement introduz uma propriedade Name.

Em geral, uma class não precisa armazenar o nome de x:Name para ser utilizável. All x:Name significa para o XAML é gerar um campo para armazenar o valor no código por trás da class. O que o tempo de execução faz com esse mapeamento é dependente do framework.

Então, por que existem duas maneiras de fazer a mesma coisa? A resposta simples é porque existem dois conceitos mapeados em uma propriedade. O WPF deseja que o nome de um elemento seja preservado no tempo de execução (que pode ser usado por meio do Bind, entre outras coisas) e o XAML precisa saber quais elementos você deseja que sejam acessíveis por campos no código por trás da class. O WPF une esses dois, marcando a propriedade Name como um alias de x: Name.

No futuro, o XAML terá mais usos para x: Name, como permitir que você defina propriedades fazendo referência a outros objects por nome, mas, em 3.5 e antes, ele é usado apenas para criar campos.

Se você deve usar um ou outro é realmente uma questão de estilo, não uma técnica. Vou deixar isso para os outros para uma recomendação.

Consulte também AutomationProperties.Name VS x: Name , AutomationProperties.Name é usado por ferramentas de acessibilidade e algumas ferramentas de teste.

Eles não são a mesma coisa.

x:Name é um conceito xaml, usado principalmente para referenciar elementos. Quando você atribui a um elemento o atributo x: Name xaml, “o x:Name especificado se torna o nome de um campo criado no código subjacente quando o xaml é processado e esse campo contém uma referência ao object.” ( MSDN ) Então, é um campo gerado por designer, que tem access interno por padrão.

Name é a propriedade de string existente de um FrameworkElement , listado como qualquer outra propriedade de elemento wpf na forma de um atributo xaml.

Como conseqüência, isso também significa que x:Name pode ser usado em um intervalo maior de objects. Essa é uma técnica para permitir que qualquer coisa no xaml seja referenciada por um determinado nome.

x: nome e nome estão fazendo referência a namespaces diferentes.

x: name é uma referência ao namespace x definido por padrão na parte superior do arquivo Xaml.

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

Apenas dizendo Name usa o namespace abaixo.

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

x: Name está dizendo use o namespace que possui o x alias. x é o padrão e a maioria das pessoas o deixa, mas você pode mudá-lo para o que quiser

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

então sua referência seria foo: name

Definir e usar espaços para nome no WPF


OK, vamos ver isso de uma maneira diferente. Digamos que você arraste e solte um botão na sua página Xaml. Você pode referenciar estas duas maneiras x: nome e nome . Todos os xmlns = “http://schemas.microsoft.com/winfx/2006/xaml/presentation” e xmlns: x = “http://schemas.microsoft.com/winfx/2006/xaml” são referências a vários namespaces . Como xaml contém o namespace Control (não 100%) e a apresentação mantém o FrameworkElement E a class Button possui um padrão de inheritance de:

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

Então, como seria de esperar, qualquer coisa que herda do FrameworkElement teria access a todos os seus atributos públicos. Assim, no caso do Button, ele está recebendo seu atributo Name de FrameworkElement, no topo da tree de hierarquia. Então você pode dizer x: Name ou Name e ambos estarão acessando o getter / setter a partir do FrameworkElement.

Referência MSDN

O WPF define um atributo CLR que é consumido pelos processadores XAML para mapear vários namespaces CLR para um único namespace XML. O atributo XmlnsDefinitionAttribute é colocado no nível do assembly no código-fonte que produz o assembly. O código-fonte do assembly WPF usa esse atributo para mapear os vários namespaces comuns, como System.Windows e System.Windows.Controls, para o namespace http://schemas.microsoft.com/winfx/2006/xaml/presentation .

Então, os atributos de assembly serão parecidos com:

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

Ambos são a mesma coisa, muitos elementos de estrutura expõem uma propriedade de nome, mas para aqueles que não podem usar x: name – eu costumo ficar com x: name porque funciona para tudo.

Os controles podem expor o próprio nome como uma propriedade de dependência se quiserem (porque precisam usar essa propriedade de dependência internamente) ou podem optar por não fazê-lo.

Mais detalhes em msdn aqui e aqui :

Alguns aplicativos de nível de estrutura do WPF podem evitar qualquer uso do atributo x: Name, porque a propriedade de dependência Name especificada no namespace do WPF para várias classs base importantes, como FrameworkElement / FrameworkContentElement, atende a esse mesmo propósito. Ainda há alguns cenários comuns de XAML e de estrutura em que o access ao código para um elemento sem a propriedade Name é necessário, principalmente em determinadas classs de suporte de animação e de storyboard. Por exemplo, você deve especificar x: Name em linhas do tempo e transformações criadas em XAML, se você pretende referenciá-las a partir do código.

Se Name estiver disponível como uma propriedade na class, Name e x: Name poderão ser usados ​​como sinônimos, mas ocorrerá um erro se ambos forem especificados no mesmo elemento.

X: nome pode causar problemas de memory se você tiver controles personalizados. Ele manterá um local de memory para a input do NameScope.

Eu digo nunca use x: Name, a menos que você precise.

A única diferença é que se você estiver usando controles de usuário em um controle do mesmo assembly, o nome não identificará seu controle e você receberá um erro “Usar x: nome para controles no mesmo assembly”. So x: Name é o versionamento de nomes de controles do WPF no WPF. Nome é usado apenas como um Legado Winform. Eles queriam diferenciar a nomenclatura de controles no WPF e winforms à medida que usam atributos no Xaml para identificar controles de outros assemblies que eles usaram x: para Nomes de controle.

Apenas tenha em mente não colocar um nome para um controle apenas por uma questão de mantê-lo como ele reside na memory como um espaço em branco e ele lhe dará um aviso de que o nome foi aplicado para um controle, mas nunca usado.

Nome :

  1. pode ser usado apenas para descendentes de FrameworkElement e FrameworkContentElement;
  2. pode ser definido de code-behind via SetValue () e propriedade-like.

x: nome :

  1. pode ser usado para quase todos os elementos XAML;
  2. NÃO pode ser definido de code-behind via SetValue (); ele só pode ser definido usando a syntax de atributo em objects porque é uma diretiva.

O uso de ambas as diretivas em XAML para um FrameworkElement ou FrameworkContentElement causará uma exceção: se o XAML for marcado como compilado, a exceção ocorrerá na compilation de marcação, caso contrário, ocorre no carregamento.

x:Name significa: crie um campo no código para manter uma referência a este object.

Name significa: defina a propriedade do nome deste object.

Eu sempre uso a variante x: Name. Não tenho idéia se isso afeta algum desempenho, apenas acho mais fácil pelo seguinte motivo. Se você tiver seus próprios usercontrols que residem em outro assembly, apenas a propriedade “Name” nem sempre será suficiente. Isso facilita ficar apenas a propriedade x: Name.

Não é um item do WPF, mas um XML padrão e o BtBh respondeu corretamente, x se refere ao namespace padrão. Em XML quando você não prefixar um elemento / atributo com um namespace, ele pressupõe que você deseja o namespace padrão. Então, digitar apenas Name não é nada mais que uma mão curta para x:Name . Mais detalhes sobre namespaces XML podem ser encontrados no texto do link

Uma das respostas é que x: name deve ser usado dentro de diferentes linguagens de programa, como c #, e o nome deve ser usado para a estrutura. Honestamente, isso é o que parece para mim.

Quando você declara um elemento Button em XAML, você está se referindo a uma class definida no tempo de execução do Windows chamado Button.

O botão possui muitos atributos, como plano de fundo, texto, margem, ….. e um atributo chamado Nome.

Agora, quando você declara um Button no XAML, é como criar um object anônimo que tenha um atributo chamado Name.

Em geral, você não pode se referir a um object anônimo, mas no processador XAML do framework WPF permite que você se refira a esse object por qualquer valor que você tenha dado ao atributo Name.

Por enquanto, tudo bem.

Outra maneira de criar um object é criar um object nomeado em vez de um object anônimo. Nesse caso, o namespace XAML tem um atributo para um object chamado Name (e, como está no espaço de nome XAML, tem X 🙂 que você pode definir para poder identificar seu object e fazer referência a ele.

Conclusão:

Name é um atributo de um object específico, mas X: Name é um atributo desse object (existe uma class que define um object geral).

O x: Name especificado se torna o nome de um campo que é criado no código subjacente quando o XAML é processado e esse campo contém uma referência ao object. No Silverlight, usando a API gerenciada, o processo de criação desse campo é executado pelas etapas de destino do MSBuild, que também são responsáveis ​​por unir as classs parciais de um arquivo XAML e seu code-behind. Esse comportamento não é necessariamente especificado em linguagem XAML; é a implementação específica que o Silverlight aplica para usar x: Name em seus modelos de programação e aplicativo.

Leia mais no MSDN …

Minha pesquisa é x:Name como variável global . No entanto, Name como variável local . Isso significa que x: Nome você pode chamá-lo em qualquer lugar no seu arquivo XAML, mas o nome não é.
Exemplo:

      

Você não pode Binding propriedade O Content do Button com Name é “btn” porque está fora do StackPanel