Setting a property based on a data value:

In this example, we have a label on a form that will display a dollar amount from our data source.  If the dollar amount is negative we want the label’s background to be red, and green if the value is positive.  To do this, we simply create a converter class in our code behind page.  This will use the numeric value and return a Brush object which we will use in our label’s Background property.  Here’s the code for the converter:

We then have to create a simple reference to our converter class in our ResourceDictionary in the Window.Resources section of our XAML:

So far so good.  Now all we have to do is bind the label’s background property to the converter and data value.  Notice that we have to bind both the label’s content (text) and background to the Amount value from our data context.  We also can set the ContentStringFormat property to automatically format the value as currency:

Setting a property based on another control’s property:

This method is useful when there isn’t a data field to bind to, but there is a need to conditionally set a control’s property.  Let’s assume we need to set a button control’s IsEnabled property based on a check box’s IsChecked property:

As you can see, we’ve bound the IsEnabled property of the buttons to the IsChecked property of  the check box by specifying the ElementName (control’s name) and Path (control’s property).  We also bound the Content property of the button to the same IsChecked property using the same method, to show the current state of the button (which the framework automatically converts from a boolean to a string).  The best part about this method?  No code behind!  Here’s the result:

This is a very simple overview of the power of converters and bindings, and how they can be used to help you do more than just display the data on your page.

However, the project required a multiple document interface (MDI), which is not supported in WPF.

After some quick thinking, I decided to try using the Windows Forms MDI while creating the WPF forms as individual WPF User Controls, and embedding them into individual Windows Forms inside the ElementHost control.  Sounds easy, right?  Well actually, it was.  In this example, I’m using Visual Studio 2010.

For example, you have a lookup form containing a textbox for entering a User ID and a button which needs to launch a new form which does a database pull and displays the user’s details.  I know you’re asking: “Why don’t you put the lookup on the same form as the results?”  Well, yes, that sounds more reasonable.  But it doesn’t help me make my example about communicating between WPF forms in the Windows Forms MDI, ok?

In your Windows Forms project, after adding an MDI Parent Form, create two new forms: one called FrmLookup and the other called FrmDetails.

Then, add two new WPF User Controls to your project, called WpfLookup and WpfDetails.  My WpfLookup control (design view) looks something like this:

The WpfDetails control (design view) will look like this:

Add an ElementHost control to each of the forms and set the Hosted Content (or Child) of the control to the appropriate WPF control.  The WPF control will then render in your Windows Form.

So now, it’s time to wire up the events to pass the User ID value from the text box to the details form.  In the WpfLookup control’s code behind, we will add the following code, which instantiates an event which we can see from the FrmLookup and contains the User ID value:

We will need to add a handler for the event in the Load event of FrmLookup.  The handler will call a function to launch the Details form inside the MDI parent form when the OnButtonClicked event is triggered in the WPF control. The code in FrmLookup will look like this:

Now you can use the User ID value passed to the Details form to populate its controls.  I won’t go into how to do that.  I’ll save the WPF data binding for another topic, but at least now you have pretty WPF forms inside a multiple document interface!