This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
In WPF, what are the differences between the x:Name and Name attributes?
Why does WPF have x:Name and Name XAML? What's the deal with x:Name?
Long story short: x:Name is an attached property and can thus be set on everything. Name is not an attached property and thus is only available on things that expose a Name property. WPF aliases Name to x:Name so you are safe to always use x:Name and this is what is recommended as you can use it everywhere.
Related
This question already has answers here:
MVVM and the TextBox's SelectedText property
(5 answers)
Closed 3 years ago.
I am new to WPF and MVVM.
I have a TextBox with some lines of text. I want to bind a piece of text highlighted by a user, to my ViewModel.
How can I do this without coding in code behind?
You cannot directly bind your selected text to a property. You have to implement a DependencyProperty and attach that but this is not trivial for beginners. A good explanation is here:
MVVM and the TextBox's SelectedText property
This question already has answers here:
Issue with DependencyProperty binding
(3 answers)
How to correctly bind to a dependency property of a usercontrol in a MVVM framework
(4 answers)
Closed 5 years ago.
I have a datagrid, which is filled by a datatable. Each entry in the table is an object of a custom type. For each cell I want to use an usercontrol to show the content. I use XamlReader to create the usercontrol in code behind.
I learned that the DataContext of the DataTemplate for the columns CellTemplate is a DataGridRow and I could access an element with the following code:
$#"<DataTemplate
xmlns=""http://schemas.microsoft.com/winfx/2006/xaml/presentation"">
<TextBox Text=""{{Binding [{count}].Amount}}"" />
</DataTemplate>"
When I try the same with my usercontrol it fails:
$#"<DataTemplate
xmlns=""http://schemas.microsoft.com/winfx/2006/xaml/presentation"">
<local:MyControl
MyProperty=""{{Binding [{count}]}}""
xmlns:local=""...
with the error:
BindingExpression path error: '[]' property not found on 'object'
Is the DataContext different when I use custom control? I don't get it...
This question already has answers here:
StringFormat is ignored
(3 answers)
Closed 6 years ago.
I have an integer value named Id and want a Label in Xaml to display the following:
(ID: 160)
I tried the following:
<Label Content="{Binding Id, StringFormat='(ID: {0:0})'} />
but it doesn't work - it just displays the value of Id:
160
How can I get this working without using a special ValueConverter class?
You have to use ContentStringFormat for content controls instead of the binding's StringFormat, has been asked various times before, will have to look for that.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What does “{x:Static}” mean in XAML?
In a xaml file there is:
Command="{x:Static src:CustomCommands.Create}"
What does the x:Static mean? If I remove it then it throws an error when loading the xaml saying it "Cannot create unknown type CustomCommands.Create"
http://msdn.microsoft.com/en-us/library/ms742135.aspx
The link above from MSDN mentions:
References any static by-value code entity that is defined in a Common
Language Specification (CLS)–compliant way. The static property that
is referenced can be used to provide the value of a property in XAML.
I am new in Silverlight.
When I add some control to my xaml file with Visual Studio it set controls name with Name property, but there is also x:Name.
Is there any difference and when to use each of them?
Thanks.
In Brief
Yes there is a difference. The bottom line is that x:Name can be used on object elements that do not have Name properties of their own.
A longer explanation
You can only use Name on an element that represents an object that actually does have a Name property. For example anything that derives from FrameworkElement.
The x:Name attribute may be placed on any element that represents an object regardless of whether that object actually has a Name property. If the object does have a Name property then the value of x:Name will be assigned to it hence you can't have both x:Name and Name on the same element.
When an object has a Name property or an x:Name property the value of that property is associated with the objects entry in the object tree. It is via the object tree that the FindName method of a FrameworkElement can find an object. FindName can find objects by name even if that object does not carry a Name property of its own since it uses the name recorded in the object tree.
The autogenerated code for a UserControl will contain field definitions for any element that that has a Name or x:Name property. The InitialiseComponent method that is generated will use the FindName method to assign values to these fields.
Example
The above Xaml creates two fields LayoutRoot of type Grid and MyBrush of type SolidColorBrush. If you were to change x:Name="LayoutRoot" to Name="LayoutRoot" that would change nothing. Grid has a Name property. However try changing x:Name="MyBrush" to Name="MyBrush". That doesn't work because SolidColorBrush doesn't have a name property. With the above Xaml you can then do code like this:-
public MainPage()
{
InitializeComponent();
MyBrush.Color = Colors.LightGray;
}
Open the definition of InitializeComponent and take a look at the auto generated code.
No, you just can't use them both. x:Name is what the XAML preprocessor actually uses and Name is just a convience property provided on the FrameworkElement class to set it.
From the MSDN reference:
If Name is available as a property on an element, Name and x:Name can be used interchangeably, but an error results if both attributes are specified on the same element.
Short answer: if you're writing stuff out in XAML, it's probably best to just use x:Name consistently.
Long answer: A previous answer mentioned that Name is a "convienience" property for accessing x:Name. That's correct. However, now that the tools environment for XAML in both Visual Studio and the Expression series has really matured and you are seeing more and more tool-generated XAML, you are also probably seeing more and more x:Name as opposed to Name. The tools prefer x:Name because that way they don't take a somewhat risky dependency (potentially specific to framework) re: how x:Name and Name are really the same, and they don't need to flipflop between setting Name if something happens to be a FrameworkElement and then x:Name on something like a Storyboard and generating a duality if you were to look at this XAML through something like a DOM. In other words, the "Name" attribute in XAML really is a lot less "convenient" to use nowadays than might have been conceived of in the original API design. Part of the "convenience" was to not have to map x:, but you have to do that anyways for x:Class and by now pretty much everyone has gotten used to using x: attributes and the general principles of XAML markup effectively.
I'm not sure of the statement made by the original poster that VS encourages using Name. Yes, Name appears as an intellisense option, but so does x:Name. And all the cases I see in the templates where an object is given a starting name are using x:Name even tho most of these are FrameworkElements.