Today I have finally booked my exam for the MCTS 70-511. Booking the exam made me reflect and just how much I had discovered about WPF since starting to revise for the exam. When I started, I had only had around a year experience with WinForms and C# and around 0 weeks of WPF development.  So here are 10 things I have discovered for anyone else who might be still working with WinForms.

1. XAML, XAML, XAML!

With WinForms you have two choices, you can use the interface designer and drag and drop components into your form or you can create and configure your components in code. Which ever one of those you choose, it will chuck up some C# in a class somewhere. Then WPF comes along looking all pretty with its XAML code. XAML is very similar to HTML in the sense you have elements and a hierarchy. If you have worked with something like android development this kind of XML/HTML style interface design will be familiar.

Why its cool:  Its Cool because it gives you much more control and structure to your interface. More importantly it makes increasingly readable layout code.

Find out more at: XAML Overview (WPF)

2. Control Templates, Gray is so last year!

When working with WinForms, if you want to customize the way a control (e.g. a button) looks you are only really faced with changing simple properties like the foreground, background, font etc. WPF has changed all that, with control templates you can visually change the control completely. You can choose what your control will show and how it will do it, you can place other controls within your control, e.g. placing a checkbox within a button.

Why its Cool: No more boring gray controls, you can make controls look however you want and its pretty simple to do.

Find out more: Customizing the Appearance of an Existing Control

3. Data Binding, The best of WPF by far

It would be a terrible crime not to talk about Data Binding when talking about WPF. Once you start using Data Binding your wonder why you spend so long writing endless SQL statements in click events. The idea of Data binding is to take away a lot of the pain of updating your source when you make a change in your application. Data binding will with a little encouragement detect when a user changes a field in your UI and will then proceed to update that value within your object which will more then likely be in a collection which will also be notified of the change. This means instead of having code all over the place updating your source (for example SQL Update statements) you can just have simple update code within your object model (your class you use to create your Customer Object for example) that does all the magic.

Why its Cool: It will save you a fair chunk of time doing boring update code. I also find it forces you into using OO design which can only be a good thing.

Find out more: Data Binding Overview

4. ClickOnce, Deployment without the hassle.

I know what your thinking, “you can deploy WinForms applications with ClickOnce”. That is correct but I don’t think it gets the attention its due so I am giving it 5 minutes of fame. If you have ever had to deploy your application to more then a few people, you would of had to create an installer. Unless your a programming God you would properly have to send out a new version of your application to fix some bugs. This can be painful, sometimes users might not of got the memo, some users might be scared to death of Installers after they opened that questionable attachment in their emails. ClickOnce may not be very configurable but it does offer a massive time safer. A integrated Updating functionality. With ClickOnce you can set a minimum required Version, you can get the application to check for updates when the app is opened or when the user exits. You can even create check for updates functionality within your application.

Why its cool: It makes updating your user base much much easier. This will save you a lot of time. It can also automatically publish itself to your FTP or network location.

Find Out more: ClickOnce Deployment Overview

5. Resource Dictionaries, CSS for .NET

XAML allows you to create styles and brushes. So what? well resource dictionaries are a revolution in recycling. You can define all your styling information (what colour your buttons background is, what size font to use) within a resource dictionary, you can then  reuse the resource dictionary not only within the same application but also if you place the resource dictionary in a separate Library you can then use those styles within other projects. This is pretty handy if you are likely to produce a number of applications that will share a consistent style as you only have to define the style once and all your applications will use the styling information. Resource dictionaries are also very versatile, you can set a style that will  automatically change every control of that type or you can give a resource a key and then reference that key within the controls you want to use the style.

Why its Cool: Its all about recycling, recycling saves time. what more do you want!

Find out more: Resources Overview

I hope that’s helped inspire those of you who are still using WinForms to move over to the WPF side.

On the application I have currently been working on I discovered a small issue. The connection string was stored as a Application setting which meant it was read-only. Its important to set the connection string as a ConnectionString type within the Application settings so that its secure.

But what happens if the connection string changes? This isn’t so bad in a internal application as you can just rollout a new build, but what if each user is likely to have a different connection string.

To change the connection string, help (as usual) came from stack overflow Programmatically change connection string.

That was all fine and dandy but when I went to go and use the application setting by going:

Properties.Settings.Default.ConString;

It returned the old unchanged connection string. the simple way round it was instead of getting the connection string using the code above I had to do this:

System.Configuration.Configuration config2 = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
 pconnectionString = config2.ConnectionStrings.ConnectionStrings["ConString"].ToString();

Bingo! that worked!

Today its been raining all day, so its been the perfect excuse to do some more WPF practice. Below I compiled a small list of useful snippets of WPF related code which have helped me out.

1. Closing all other WPF Windows when closing a main window

Normally in an application your have a main WPF window that does some essential functionality. An example could be your web browser. The browser window is the main window and you may have an extra window which you can manage your bookmarks.

A quick and easy way I found to do this was create an event handler for the “Closing” event for the main window:

Closing="Window_Closing"

In the event handler we do this:

private void Window_Closing(object sender, System.ComponentModel.CancelEventArgs e)
{
       foreach (Window win in App.Current.Windows)
       {
            if (win != this)
            {
                 win.Close();
            }
       }
}

The real gem here is the App.Current.Windows collection, which does what it says on the tin and has a collection of all the windows that have been created in your application. An important part of the snippet above is that we make sure to not close the Window that the code belongs to otherwise you get an Exception, trust me I tried it!

2.  Open an Existing instance of a WPF Window instead of a new instance

Picture the scene, your creating an address book application and to add a new contact you have set it to bring up a new Add Contact Window. Once you finish you WPF application and release it out in the wild you get a angry email from Timmy, a frustrated user. For some reason they have 53 instances of the Add Contact Window open!

Now to keep poor Timmy happy what you need to do is before opening a new instance of your WPF Window you want to make sure that none are already open.

And using the same magic as above you do the following:

foreach(Window win in App.Current.Windows)
{
    if (win.GetType() == typeof(propertiesWindow))
    {
        win.Show();
        win.Focus();
        return;
    }
}

What we are doing is looping through the collection of WPF Windows within your application and then checking if any of the windows are of the type we are wanting to open. If it does find one with the same type it will show the Window to the screen, if not it will do nothing.

3. WPF Visibility Property

Before I started learning the wonders of WPF, I worked with WinForms. With WinForms, life was simple, a Form or Component was either Visible = true or Visible = false. Along comes WPF stomping all over WinForms and worst of all forcing its three states of visibility on us!

After I found out what that third state was, I was willing to forgive WPF because its pretty handy. the third state is:

usrAddBtn.Visibility = System.Windows.Visibility.Collapsed;

Collapsed makes the WPF Element not only invisible but doesn’t reserve the space within the Parent Element. What does this mean in the real world? well it means that you could collapse a Panel and place a new Panel in its placed. This means that instead of creating new WPF Windows for settings pages for example,  you can reuse the space of your main Window.