WPF ItemsControl in-depth interpretation of items and ItemsSource

I believe that many WPF developers have some understanding of the controls, from the early Microsoft MFC, found that WPF programming is more convenient. But there is still a vast array of information to be learned. Control is a topic that WPF development does not revolve around. Today we start by analyzing the ItemsControl control.

ItemsControl can contain multiple items, and the magic is that it can contain a string or a full user-defined class object, and can even contain button buttons, StackPanel controls, which are Listbox,listview, TreeView and other controls, but ItemsControl can also be used directly as a WPF control.

First we look at the definition of items and ItemsSource two properties in ItemsControl:

1 Below is an example of adding items through the ItemsControl Items property:

The effect is as follows:

This usage is to add <ItemsControl.Items> directly to the Xmal file to achieve the added item. But this way it seems that only one item can be added.

2 below the second example, how to add multiple items through the ItemsControl Items property, need to be achieved by code, as follows the code for the Xmal file:

The corresponding source code for this ItemsControl added is as follows:

The results are as follows:

Visible ItemsControl items can be added to any object, can be a string, can be a button, and so on.

3 According to Microsoft's official documentation, specify the source of the ItemsSource property, that is, assign a IEnumerable type object to the ItemsSource property, or you can add an item. It is important to note that after you set the property value on ItemsSource, the Items property becomes read-only and the items size becomes a fixed size, which means that items cannot be added through the Items property. When a IEnumerable type object has been set before the ItemsSource property, and then the ItemsSource is set to null by code, the entire collection item is deleted and the Items property is restored to use. Just now items are an empty ItemCollection object.

example, set ItemsSource to {Binding path=strlist} in Xmal

The source file defines a public strlist object (belonging to the List<string> class or other IEnumerable Class):

The effect is as follows:

Now, let's do an experiment that uses the Items property of the ItemsControl control to add another item:

At this point, the following exception occurs after the run:

================== here for the split line, familiar with the binding brothers and sisters can no longer look down =========================

So here's a little digression--binding, ItemsControl the control's ItemsSource binding using the following binding extension expression:

Itemssource= "{Binding path=strlist}"

This is a use of binding, which is completely equivalent to

Itemssource= "{Binding strlist}"

Binding extended syntax expression the first property defaults to path, which can be omitted. The official explanation for path is as follows:

The above means that the assignment to path must be an attribute, if the above example strlist is defined as the following ordinary member:

Public list<string> strlist;

That is, if you remove the Set,get (through the experiment, you actually need to have get), then the path binding is not valid.

The other is that WPF has a set of binding engines in motion that automatically obtains the properties of an object by assigning a string to the path, which is done automatically.

For another example, suppose there is another class called MyData that contains an object strlist of a list<string> attribute:

This time simply change the xmal to read as follows:

Effect is the same:

In the example above, MyData is a property, Strlist is also a property, so Binding is written as Itemssource={binding mdata.strlist}.

In addition to this, it is important to note that although the assignment path must be a property, the seemingly binding source must be a property. However, it is not true that the binding source does not necessarily have to be a property, as in the following example (this example comes from the official website):

This example tells us that the source property can be used to bind a feed, at which point the binding source has no special requirements and can be not a property. So the conclusion is:

If you specify a binding source through path, then you must follow a Property object;

If you specify a binding source through source, you can be either an attribute or any object.