BINDING MODES in Visual C#.NET

Drawing PDF 417 in Visual C#.NET BINDING MODES

There are four binding modes in WPF: OneTime, OneWay (to target), OneWayToSource, TwoWay, and Default. We know what you re probably thinking that we can t count. You re suspicious because we listed five items. Default isn t a mode per se it figures out the most appropriate of the other modes to use. Table 11.1 describes the different modes in a little more detail.

target of the data binding operation once. The advantage here is performance because, once the data is copied, the framework can forget that the binding exists. For data sources that aren t expected to change during the execution of the program (like the operating system version or, perhaps, certain machine configuration settings) or where manually forcing the binding to update is reasonable, this may be the best mode to bind with.

There are two OneWay modes. OneWay (or more precisely: OneWayToTarget) never tries to write the value back to the source. For the cases when you want to expose some underlying data in the UI, but the data is readonly or otherwise not meaningful to modify, OneWay is the one true way. OneWay is the most common OneWay binding mode. The cases for OneWayToSource are rare, but when you need it, it s nice to have. Whenever the binding target changes, OneWayToSource copies the data to the source, effectively making this a reverse binding. OneWayToSource allows data binding with a target that isn t a DependencyProperty.

TwoWay represents the common business logic scenario in which you have some business data to load and reflect in the UI; when the data is changed in the UI, the changes are automatically propagated back to the business object. This mode saves a lot of manual updating of values to and from data objects.

Not setting the binding mode and setting it to Default have the same effect. In either case, the target DependencyProperty is examined, and the system automatically selects the most appropriate mode. In our first example, the ProcessMonitor, we re presenting a read-only list of values, so our binding will be OneWay.

Our first binding example is like a little TaskManager, in that it shows a list of all the processes; it s also unlike TaskManager, in that you can t do anything with the list of processes like shutting things down. Figure 11.2 shows what the final application will look like. To follow along, create a new WPF Application called ProcessMonitor. Then, create a new Window called Monitor.xaml. This is our main window, so you ll need to update the StartupURI in App.xaml to point to Monitor.xaml instead of Window1.xaml. If you re feeling especially tidy, you can go ahead and delete Window1.xaml it s kind of annoying anyway. With that done, we re ready to get started.

11.2.1 Binding Data with XAML The first thing we need is some data. It turns out that System.Diagnostics has a class for manipulating process information called, cleverly enough, Process. Process

Because we have a list of data for the source, we ll also want a list control to show it. We drag a ListView over from the Toolbox, remove the automatically created Margin attribute, and split the tag because we re going to be doing some XAML surgery soon.

Now we need access to that Process class from the XAML. This class is available in the System.Diagnostics namespace of the System assembly, so we add the assembly via the XML namespace using statement xmlns:diag="clr-namespace:System.Diagnostics;assembly=System." The Window tag should look like this:

<Window x:Class="ProcessMonitor.Monitor" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:diag="clr-namespace:System.Diagnostics;assembly=System" Title="Monitor" Height="400" Width="400">

WPF provides two classes to help bind data: ObjectDataProvider and XmlDataProvider. These classes are derivations of DataSourceProvider. This is the class that we d extend if we want to expose some custom form of data that isn t supported in the way we want. We ll try the XmlDataProvider a little later, but for this task, we need the ObjectDataProvider. These classes are adapters that WPF uses to bind to particular types of data, and are designed so that they can be described declaratively in XAML. They also allow asynchronous binding so that the UI can operate while data is being loaded.