I agree with John Simmons in that you will most likely have to convert most of the application by hand. And, if you're doing this just to make it pretty, then maybe you shouldn't bother.
That being said, if you still want to go through with this, there are a few things you need to know:
- System.Collection.ObjectModel.ObseverableCollection<T>(s) are your friends.
- The App class is the starting point, don't replace this starting because you want the main method back.
- The XAML page for the App class is where you store you application wide resources. Sure, you can define these resources in a dictionary file and instantiate that file in each window/control, but then you'll end up with multiple copies of the same items all over the place (this is what you'll end up doing if you replace the App class as your starting point).
- The App class has events you can use to insert code that need to run before the MainWindow is opened and after you close it. Remember this is event based so having a using(var x = ...){ } statement will NOT span the entire application. This code will need to be split apart.
- Take a good look at the MVVM pattern. There's some stuff in there that I thought was really stupid. Then one day, I was porting sections of a WinForms app into a WPF app, and I thought, "If I had done <blank> from the start, this would be a lot easier." Then I remembered that MVVM does <blank> and it no long seemed like a stupid thing to do.
- DependencyObjects can only have one parent in the VisualTree (it's possible to try to give them two parents by making them into a resource).
- The DataContext is not part of the VisualTree path, it's just the starting point for your binding objects.
- A template will build every item in the template for the object you apply the template to. If the template contains a reference to another resource, it will build a reference to that resource. So that resource better NOT be something that can only show up in one spot of the VisualTree.
- Find a snippet(s) for implementing System.ComponentModel.INotifityPropertyChanged, it will save you a lot of time, effort, and debugging.
- The WPF way isn't always the best way, somethings are just a lot easier to do in code then in bindings (real time propagation of RadioButton selection). I took me months of always trying to do it the WPF before I started to get a good sense of when I should just do it in code.
Submit an article or tip