2009-02-26 4 views
476

В названии говорится все. Иногда кажется, что атрибуты Name и x:Name взаимозаменяемы.В WPF, каковы различия между атрибутами x: Name и Name?

Итак, каковы окончательные различия между ними, и когда предпочтительнее использовать один над другим?

Есть ли какое-либо влияние производительности или памяти на использование их неправильным способом?

EDIT Ответы до сих пор говорят о том, что использование x:Name все время работает нормально, но я все еще хочу знать, в чем разница. Microsoft поместила эти два атрибута в самый первый выпуск WPF, поэтому должно быть какое-то разумное объяснение.

+0

Ответы предполагают, что использование 'x: Name' все время работает нормально. Мне просто пришлось изменить его на «Name», иначе я не мог бы ссылаться на элемент управления в моем .xaml.cs-коде, поэтому я собираюсь предположить, что это уже не так, что он работает нормально все время. – Ortund

ответ

420

В XAML действительно есть только одно имя: x:Name. Фреймворк, такой как WPF, может по желанию сопоставить один из его свойств с x:Name XAML, используя RuntimeNamePropertyAttribute в классе, который обозначает одно из свойств классов как отображение атрибута x: Name XAML.

Причина этого заключалась в том, чтобы разрешить создание фреймворков, которые уже имеют концепцию «Имя» во время выполнения, например WPF. Например, в WPF FrameworkElement вводит свойство Name.

В целом, класс не должен хранить имя для x:Name для использования. Все x:Name означает, что XAML генерирует поле для хранения значения в коде за классом. То, что среда выполнения делает с этим сопоставлением, зависит от структуры.

Итак, почему существуют два способа сделать то же самое? Простой ответ, потому что есть два понятия, отображаемых на одно свойство. WPF хочет, чтобы имя элемента сохранялось во время выполнения (которое можно использовать через Bind, между прочим), и XAML должен знать, какие элементы вы хотите получить по полям в классе за классом. WPF связывает эти два вместе, отмечая свойство Name как псевдоним x: Name.

В будущем XAML будет иметь больше применений для x: Name, например, позволяя вам устанавливать свойства, ссылаясь на другие объекты по имени, но в 3.5 и ранее он используется только для создания полей.

Следует ли использовать тот или иной вопрос, а не технический. Я оставлю это другим для рекомендации.

См. Также AutomationProperties.Name VS x:Name, AutomationProperties.Name используется средствами доступности и некоторыми инструментами тестирования.

+2

В Visual Studio 2010 свойство Name устанавливается (а не x: Name) при редактировании XAML через конструктор. Кажется, что MS поощряет использование имени над x: Name, поэтому я думаю, что это стандарт defacto. – Nebula

+7

Я не думаю, что эти два являются взаимозаменяемыми в целом. Для именования пользовательских элементов управления требуется 'x: Name', потому что' Name' не создаст поля для распознавания кода. Я все еще не знаю, почему это происходит. – Libor

+3

Они не так и не подразумевают, что они это сделали. В WPF, если элемент имеет свойство «Name», это означает одно и то же. Если элемент не имеет свойства 'Name', вы должны использовать' x: Name'. – chuckj

5

Я всегда использую вариант x: Name. Я понятия не имею, влияет ли это на какую-либо производительность, я просто нахожу это проще по следующей причине. Если у вас есть собственные пользовательские элементы управления, которые находятся в другой сборке, свойство «Имя» не всегда будет достаточным. Это упрощает просто придерживаться свойства x: Name.

+4

Если нет никакой разницы, тогда почему было бы два способа сделать то же самое? Оба способа существовали в первой версии WPF. –

17

Они оба одинаковы, многие элементы фреймворка сами выставляют свойство имени, но для тех, кто не может использовать x: name - я обычно просто придерживаюсь x: name, потому что он работает на все ,

Элементы управления могут показывать имя как DP, если они хотят (потому что они должны использовать этот DP внутри), или они могут отказаться.

Подробнее в MSDN here и here:

Некоторые приложения рамки уровня WPF может быть в состоянии, чтобы избежать использования х: атрибут Name, так как свойство зависимостей Имя как указано в пространство имен WPF для нескольких важных базовых классов, таких как FrameworkElement/FrameworkContentElement , удовлетворяет этой же цели. Есть еще некоторые общие XA и рамки сценариев, в которых коды доступ к элементу без собственности зовут необходимо, прежде всего в определенной анимации и раскадровке поддержке классов. Например, вы должны указать x: имя по срокам и преобразования, созданные в XAML, если вы намерены ссылаться на них из кода.

Если имя доступно в качестве свойства на класс, имя и х: Имя может быть использовано взаимозаменяемо как атрибуты, но ошибки приведет, если оба указанных в том же элементе.

+3

Если нет никакой разницы, тогда почему бы было два способа сделать одно и то же? Оба способа существовали в первой версии WPF. –

+0

Lol, вы проголосовали за все ответы? –

+0

@Steve, я не ответил ни на один из ответов на этот вопрос, хотя ни один из них до сих пор не был очень уместным. –

27

x: Имя и имя ссылаются на разные пространства имен.

x: name - это ссылка на пространство имен x, определенное по умолчанию в верхней части файла Xaml.

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

Просто сказать Имя использует по умолчанию ниже имен.

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

х: Имя говорит использовать пространство имен, которое имеет псевдоним х. х по умолчанию, и большинство людей покинуть его, но вы можете изменить его на то, что вам нравится

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

так что ваша ссылка будет Foo: имя

Define and Use Namespaces in WPF

EDIT:

OK Давайте посмотрим на это по-другому. Скажем, вы перетащите кнопку на свою страницу Xaml. Вы можете ссылаться на этот 2 пути x: name и имя. Все XMLNS = "http://schemas.microsoft.com/winfx/2006/xaml/presentation"и XMLNS: х = "http://schemas.microsoft.com/winfx/2006/xaml" - это ссылки на несколько пространств имен. Поскольку XAML держит управления пространства имен (не 100% от этого), и презентации держит FrameworkElement И класс Кнопки имеет рисунок наследования:

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

Так как можно было бы ожидать все, что наследует от FrameworkElement, будет иметь доступ ко всем его публичным атрибутам. поэтому в случае Button он получает свой атрибут Name из FrameworkElement, на самой вершине дерева иерархии. Итак, вы можете сказать x: Имя или Имя и оба они будут обращаться к устройству-получателю/Элементу FrameworkElement.

MSDN Reference

WPF определяет атрибут CLR, который потребляемые процессоры XAML, чтобы сопоставить несколько пространств имен CLR для одного пространства имен XML. Атрибут XmlnsDefinitionAttribute размещен на уровне сборки в исходном коде, который создает сборку. Исходный код сборки WPF использует этот атрибут для сопоставления различных общих пространств имен, таких как System.Windows и System.Windows.Controls, с пространством имен http://schemas.microsoft.com/winfx/2006/xaml/presentation.

Так атрибуты сборки будет выглядеть примерно так:

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

Я не думаю, что это правда, что 'http: // schemas.microsoft.com/winfx/2006/xaml' содержит' Control', так как вы можете использовать его непосредственно в XAML без пространства имен 'x': '' –

3

Это не элемент WPF, но стандартный XML один и BtBh правильно ответил, х относится к пространство имен по умолчанию. В XML, когда вы не префикс element/attribute с пространством имен, предполагается, что вы хотите использовать пространство имен по умолчанию. Так что набрав только Name - это не более чем короткая рука для x:Name. Более подробную информацию о пространствах имен XML можно найти по адресу link text

+0

Соблазненный to -1 x: относится к другому пространству имен XML, true, но на самом деле это не полезный ответ Q, который касается того, когда вам нужно использовать один другой. :/ –

66

Это не одно и то же.

x:Name - концепция xaml, используемая в основном для ссылок на элементы. Когда вы даете элементу атрибут x: Name xaml, «указанное x:Name становится именем поля, которое создается в базовом коде при обработке xaml, и это поле содержит ссылку на объект». (MSDN) Итак, это созданное конструктором поле, которое по умолчанию имеет внутренний доступ.

Name - это существующее свойство строки FrameworkElement, перечисленное как любое другое свойство элемента wpf в виде атрибута xaml.

Как следствие, это также означает, что x:Name может использоваться для более широкого круга объектов. Это метод, позволяющий ссылаться на что-либо в xaml на указанное имя.

+4

Итак, почему можно использовать имя Name или x: Name с Binding.ElementName? Кажется, что атрибут x: Name используется не только для имени поля в сгенерированном коде, но и для метаданных во время выполнения. –

+0

Это сгенерированное поле, подобное полю Name в свойствах Design редактора WinForms. Там вы поместите имя в список свойств, и оно станет полем. Это то же поведение. Конечно, он доступен во время выполнения, поскольку это внутреннее поле, скомпилированное в код позади. Binding.ElementName проверяет любой случай, то есть редактор xaml «magic», x: Name не является магическим по себе. –

9

X: Имя может вызвать проблемы с памятью, если у вас есть настраиваемые элементы управления. Он сохранит ячейку памяти для записи NameScope.

Я говорю, никогда не используйте x: Name, если вам не нужно.

+0

Согласовано. Работала над приложением киоска, которое имело многочисленные утечки памяти и разрешение предыдущей команды разработчиков, чтобы просто перезагрузить компьютер. Большая часть утечек была легко идентифицирована. Тем не менее, после исправления найденных через IntelliTrace и JustTrace, некоторые ссылки все еще ускользают от неявной и явной сборки мусора. Я читал: http://support.scichart.com/index.php?/ News/NewsItem/View/21/wpf-xname-memory-leak - как сделать-память-память-в-scichart Обнаружено, что сокращение x: Name повышает производительность. – MachinusX

+0

Это мое понимание этого влияет на _both_ ** Имя ** и ** x: Имя **, поскольку оба они добавлены в NameScope. Если вам нужно имя в вашем элементе, его не обойти. Вы можете воспроизводить код в элементе без имени через ['FrameworkElement.RegisterName (" elementname ")'] (https://msdn.microsoft.com/en-us/library/system.windows.frameworkelement.registername (v = vs.110) .aspx). Однако, если вы вызываете ['FrameworkElement.UnregisterName (" elementname ")'] (https://msdn.microsoft.com/en-us/library/system.windows.frameworkelement.unregistername (v = vs.110) .aspx) он может быть «разыменован». –

7

Единственное отличие состоит в том, что если вы используете пользовательские элементы управления в элементе управления из той же сборки, то Name не будет идентифицировать ваш элемент управления, и вы получите сообщение об ошибке «Используйте x: имя для элементов управления в той же сборке». Итак, x: Имя является версией управления именами WPF в WPF. Имя используется как наследие Winform.Они хотели различать имена элементов управления в WPF и winforms, поскольку они используют атрибуты в Xaml для идентификации элементов управления из других сборок, которые они использовали x: для имен управления.

Просто имейте в виду, не помещайте имя для элемента управления только ради сохранения его, поскольку оно находится в памяти как пустое, и оно даст вам предупреждение о том, что имя было применено для элемента управления, но его никогда не использовалось.

7

Имя:

  1. могут быть использованы только для потомков FrameworkElement и FrameworkContentElement;
  2. может быть установлен с помощью кода через SetValue() и свойства.

х: Имя:

  1. может быть использован практически для всех XAML элементов;
  2. НЕ МОЖЕТ быть установлен с с помощью SetValue(); его можно установить только с использованием атрибута на объекты, потому что это директива.

Используя обе директивы в XAML для одного FrameworkElement или FrameworkContentElement вызовет исключение: если это XAML разметки компилируется, исключение будет происходить на компиляции разметки, в противном случае это происходит при загрузке.

2

Один из ответов заключается в том, что x: имя должно использоваться внутри разных языков программы, таких как C#, и имя должно использоваться для фреймворка. Честно говоря, это то, что мне кажется.

5

x:Name средство: создать поле в коде для хранения ссылки на этот объект.

Name означает: свойство свойства этого объекта.

+0

Это не совсем так; они оба доступны из кода, но достаточно интересно, что только x: Name может обновляться во время выполнения. Чокнутый. – Will

1

Указанное x: Название становится именем поля, которое создается в базовом коде при обработке XAML, и это поле содержит ссылку на объект. В Silverlight, используя управляемый API, процесс создания этого поля выполняется шагами назначения MSBuild, которые также отвечают за объединение частичных классов для файла XAML и его кода. Это поведение не обязательно указано на языке XAML; это особая реализация, которую Silverlight применяет для использования x: Имя в своих моделях программирования и приложений.

Read More on MSDN...

2

При объявлении элемента Button в XAML вы имеете в виду класса, определенного в окна во время выполнения под названием Button.

Кнопка имеет много атрибутов, таких как фон, текст, поле, ..... и атрибут Name.

Теперь, когда вы объявляете кнопку в XAML, это похоже на создание анонимного объекта, у которого был атрибут Name.

В целом вы не можете ссылаться на анонимный объект, но в инфраструктуре WPF XAML-процессор позволяет вам ссылаться на этот объект по любому значению, присвоенному атрибуту Name.

Пока все хорошо.

Другой способ создания объекта - создать именованный объект вместо анонимного объекта. В этом случае пространство имен XAML имеет атрибут для объекта с именем Name (и поскольку в пространстве имен XAML есть X :), вы можете установить его таким образом, чтобы вы могли идентифицировать свой объект и ссылаться на него.

Вывод:

Имя является атрибутом конкретного объекта, но X: Имя является одним атрибутом этого объекта (есть класс, который определяет общий объект).

Смежные вопросы