We Keep Coding

XAML (WPF) Namespace?

I have been trying to read up on XAML namespace and the use of xlmnr and it has been kind of fuzzy. Either it is too technical, or too simplistic.
My question is a little similar to a question asked here, but my question has more to do with the x part attached to it.
So:
Does the xmlns:x, mean a secondary namespace? i.e. the non-default one? Can I have more than one, and if so what order does the search for the right class go in? This of course assumes that xmlns is the default one.
What about the meaning of and difference of attaching x:name as opposed to name to a tag?
Edit:
Turns out, I think I completely misunderstood it. There is no search hiearchy like C# using statement, or java's import. The xmlns:<name> is more like a way to define a name that you can access a whole tree of classes. The x on the other hand is a conventional way to define XMAL related stuff, but is not a requirement.
Can anyone confirm?

The use of XML namespaces in XAML is necessary because of the underlying XML technology used.
xmlns:x indeed creates a second namespace named x. You can reference attributes, etc from it using x:....
If you had simply use name instead of x:name it would have referenced the default namespace.
You can have as much namespaces declared in your XAML as needed.

The standard x namespace exposes common XAML features - basically a mapping of various things that are implemented in code to give them meaning in the XAML context. In the case of x:Name (not x:name - case matters) the XAML compilation process creates a code-behind field based on the x:Name value. The non-x Name property is an attribute representing the Name property on the WPF FrameworkElement base class, which in most cases works the same way as setting the x:Name, and you can't assign both on the same element. See this question for more info.
To the first part of your question: you can change the x to whatever you want, but shouldn't to maintain consistency, and can also (and will in practice) add other xmlns: declarations, primarily to access additional feature implemented in code. For example, if you work in Blend you will often see a xmlns:d added which contains a bunch of designer specific properties. Any code that you need to reference, like data types, converters, etc. will generally use an xmlns: with clr-namespace and assembly specified to map to the .NET namespace in the code: i.e. xmlns:local="clr-namespace:WpfApplication1"

WPF Binding Fundamentals [duplicate]

This question already has an answer here:
When to use Path in WPF Binding?
(1 answer)
Closed 9 years ago.
I am very new to WPF and the binding. I see the following through the application and I was wondering what the difference is.
{Binding aField}
{Binding Path=aField}
When should I use one over the other?

There is no difference; In the first example you are creating the binding using the constructor Binding(string), in the second one you are assigning a property using the initializer, calling the Binding() constructor

There is no difference. Path is a default property and does not need to be specified in binding markup extension MSDN:
The Binding markup extension uses Binding.Path as a conceptual "default property", where Path= does not need to appear in the expression. If you specify a Binding expression with an implicit path, the implicit path must appear first in the expression, prior to any other bindProp=value pairs where the Binding property is specified by name. For example: {Binding PathString}, where PathString is a string that is evaluated to be the value of Binding.Path in the Binding created by the markup extension usage. You can append an implicit path with other named properties after the comma separator, for example, {Binding LastName, Mode=TwoWay}.

How can a WPF binding distinguish between an indexer property and a list element?

I have a binding of the form:
Path=SpecialCollection[0]
The SpecialCollection class extends ObservableCollection and has an indexer property.
public T this[string propertyValue]
{
get
{
// do stuff
return default(T);
}
}
My problem is that the binding attempts to get the indexer property value, instead of returning the 0th item in the collection. Is there a way to force the binding to treat 0 as an integer so it returns a collection element, instead of invoking the collection's indexer property's getter?

According to MSDN you can tell the binding the type of the value entered as index:
Inside indexers you can have multiple indexer parameters separated by commas (,). The type of each parameter can be specified with parentheses. For example, you can have Path="[(sys:Int32)42,(sys:Int32)24]", where sys is mapped to the System namespace.
I noticed that the Binding constructor taking a path string uses another PropertyPath constructor than the default PropertyPath type converter, said PropertyPath constructor does not work in this scenario. To avoid the problem avoid the Binding constructor by setting the Path property manually which invokes the conversion via type converter.
<!-- Does not work -->
<TextBlock Text="{Binding [(sys:Int32)0]}"/>
<!-- Does work -->
<TextBlock Text="{Binding Path=[(sys:Int32)0]}"/>

Actually you have two indexer properties, one that takes an int argument and one that takes a string argument. Frankly, I don't know how the binding expression chooses which indexer to use when it is ambiguous. If there is only one then it can coerce the index to the type of the indexer argument. If there are two, it can either throw an exception or choose one according to a heuristic. In this case, it apparently chose the wrong one.
To solve this problem you can either move your string indexer "down a level" so it hangs off of a new property so that it doesn't compete with the list indexer or if all you need is List[0] you can add a First property and bypass either indexer.

"Prefix 'x' does not map to a namespace"

I want to load a DataTemplate at runtime using XamlReader, but it's throwing the exception "Prefix 'x' does not map to a namespace."
This is the XML string I'm passing to XamlReader:
<xm:ResourceDictionary
xmlns:xm="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:do="clr-namespace:MyLibrary.DataObjects;assembly=MyLibrary.DataObjects"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<xm:DataTemplate DataType="{x:Type do:ValidationResponse}">
<xm:StackPanel Orientation="Horizontal">
<xm:Label>MessageID</xm:Label>
<xm:TextBox Text="{Binding Path=MessageID}"/>
</xm:StackPanel>
</xm:DataTemplate>
</xm:ResourceDictionary>
This is the code that's reading it:
ResourceDictionary dictionary = XamlReader.Parse(myXamlString) as ResourceDictionary;
Here's the funny part, if I add x:Key="ValidationResponseTemplate" to the DataTemplate it parses without any exceptions. I can't keep it that way, however, because I can't specify the DataTemplate by key in the program's own .xaml (it won't know about the template until it gets fetched at runtime).
The x namespace is defined in both the program's own .xaml and in the fragment of XML I'm trying to parse.
Overall objective: be able to provide new DataTemplates to both change the appearance of the display at runtime, and to display XML data that the client did not know about at compile-time.

Found a way around it: rather than have XamlReader parse a string, it worked better if I gave it an XmlReader. The fragment of XML with the DataTemplate defined in it was part of a larger XML document that had all its namespaces defined in its root. This had already been read into an XDocument, and out of which I'd grabbed the XElement with the ResourceDictionary defined in it. The new code, part of MainWindow.xaml.cs, looks like this:
ResourceDictionary dictionary = XamlReader.Load(myXElement.CreateReader()) as ResourceDictionary;
this.Resources.MergedDictionaries.Add(dictionary);
This threw a different exception, where it couldn't resolve the type of (http://myschemas/MyProfile)Binding. It turns out that you need to qualify the namespaces of everything, including the {Binding ...} references. So the XML fragment had to be amended to:
<xm:TextBox Text="{xm:Binding Path=MessageID}"/>
Now XamlParser knew that Binding was a type in the "http://schemas.microsoft.com..." namespace.

What is a dependency property? What is its use? [duplicate]

This question already has answers here:
Closed 11 years ago.
Possiblity:
What is a dependency property?
What is a dependency property? How does it differ from a normal property? What is the purpose of dependency properties? And why it is used, when it is used?

Dependency property: A property that is backed by a DependencyProperty.
The purpose of dependency properties is to provide a way to compute the value of a property based on the value of other inputs.
These other inputs might include system properties such as themes and user preference, just-in-time property determination mechanisms such as data binding and animations/storyboards, multiple-use templates such as resources and styles, or values known through parent-child relationships with other elements in the element tree.
It has Following capabilities:
The property can be set in a style.
The property can be set through data binding.
The property can be set with a dynamic resource reference.
The property can inherit its value automatically from a parent element in the element tree.
The property can be animated.
The property can report when the previous value of the property has been changed and the property value can be coerced.
The property reports information to WPF, such as whether changing a property value should require the layout system to recompose the visuals for an element.
The property receives support in the WPF Designer for Visual Studio. For example, the property can be edited in the Properties window.
(Content taken from MSDN)

Dependency properties store their values outside the class, so properties can be assigned to an object without having to change the object's class. They also support a situation common in WPF where an object may have very many properties, but only a few have non-default values. Dependency properties can have default values, so this reduces memory usage. There is lots more, read the article: Dependency Properties Overview on MSDN.

I think the MSDN article can give you more information.
From what I read is that a Dependency Property relies on other values.
The purpose of dependency properties
is to provide a way to compute the
value of a property based on the value
of other inputs. These other inputs
might include system properties such
as themes and user preference,
just-in-time property determination
mechanisms such as data binding and
animations/storyboards, multiple-use
templates such as resources and
styles, or values known through
parent-child relationships with other
elements in the element tree. In
addition, a dependency property can be
implemented to provide self-contained
validation, default values, callbacks
that monitor changes to other
properties, and a system that can
coerce property values based on
potentially runtime information.
Derived classes can also change some
specific characteristics of an
existing property by overriding
dependency property metadata, rather
than overriding the actual
implementation of existing properties
or creating new properties.

If you are talking about a property with a Dependency attribute (as defined in Microsoft.Practices.Unity)
[Dependency]
public string MyProperty { get; set; }
Then this is used for dependency injection (DI) by the Unity framework. Basically, the property value is set at runtime by the DI framework, rather than being set directly in your code.
However, there is another Dependency attribute defined in System.Runtime.CompilerServices. Please could you update your question with which one you mean.