There really is only one name in XAML, the x:Name
. A framework, such as WPF, can optionally map one of its properties to XAML's x:Name
by using the RuntimeNamePropertyAttribute
on the class that designates one of the classes properties as mapping to the x:Name attribute of XAML.
The reason this was done was to allow for frameworks that already have a concept of "Name" at runtime, such as WPF. In WPF, for example, FrameworkElement
introduces a Name property.
In general, a class does not need to store the name for x:Name
to be useable. All x:Name
means to XAML is generate a field to store the value in the code behind class. What the runtime does with that mapping is framework dependent.
So, why are there two ways to do the same thing? The simple answer is because there are two concepts mapped onto one property. WPF wants the name of an element preserved at runtime (which is usable through Bind, among other things) and XAML needs to know what elements you want to be accessible by fields in the code behind class. WPF ties these two together by marking the Name property as an alias of x:Name.
In the future, XAML will have more uses for x:Name, such as allowing you to set properties by referring to other objects by name, but in 3.5 and prior, it is only used to create fields.
Whether you should use one or the other is really a style question, not a technical one. I will leave that to others for a recommendation.
See also AutomationProperties.Name VS x:Name, AutomationProperties.Name is used by accessibility tools and some testing tools.
Typically a control is rendered for its own sake, and doesn't reflect underlying data. For example, a Button
wouldn't be bound to a business object - it's there purely so it can be clicked on. A ContentControl
or ListBox
, however, generally appear so that they can present data for the user.
A DataTemplate
, therefore, is used to provide visual structure for underlying data, while a ControlTemplate
has nothing to do with underlying data and simply provides visual layout for the control itself.
A ControlTemplate
will generally only contain TemplateBinding
expressions, binding back to the properties on the control itself, while a DataTemplate
will contain standard Binding expressions, binding to the properties of its DataContext
(the business/domain object or view model).
Best Answer
Stefan,
I think that you can do this by creating Design Time class as described in the link below:
http://karlshifflett.wordpress.com/2008/10/11/viewing-design-time-data-in-visual-studio-2008-cider-designer-in-wpf-and-silverlight-projects/
Hope this helps.