Is it better to use WPF over Windows Forms?
We dealt with this question about 9 months ago. We decided to go with WPF and so far we're happy with the decision. Yes, there is a learning curve. It's fairly considerable especially coming from WinForms where you have so much to unlearn. I also recommend you have access to a designer otherwise your application will probably look a bit shabby. Also be prepared for some WPF gotchas that will have you spending hours scratching your head saying 'why was this so hard'.
But WPF is a step ahead. The data binding, templating and complete control of how you want your windows to look makes you think that this how WinForms should've been originally.
Oh yes, and be prepared to shell out a couple of dollars for some missing controls. There are a couple of things missing like a Date picker and having checkboxes on tree controls (you can actually template this out, but it's not as simple as winforms in that regard). 3.5 SP1 includes a grid control now, thankfully.
I'm sure I'm missing a bunch more, but that's what I can come up with off the top of my head.
Good luck!
I know this is an old post, but I think it's still a valid question.
I used WinForms for 3 years at the first company I worked for. There were some really good programmers there, and they found some very clever ways to do some very cool things. WinForms has stood the test of time. It is a solid, reliable and efficient platform. Many people, and many companies both large and small have been using WinForms for years, and the technology has proven itself time and time again. Inertia like that is hard to fight, even if you are Microsoft.
Still, WPF is definitely the future. Microsoft made that clear by making products such as Visual Studio 2010 and Expression Blend with it. (In using WPF for internal projects, Microsoft was forced to fix many of the issues, such as font rendering and speed issues, that prevented people from adopting it at first. Visual Studio 2010 shows that WPF has long been ready for production.
So, is it better to write your program in WinForms or WPF? The answer is this : WPF. I say this for two reasons. Firstly, because Microsoft is supporting it internally, we can assume that it will be around for a very long time. Microsoft has shown us that it is the next tool of choice which leads me to my next point: it has become superior to WinForms (some people I have spoken to disagree, but it is the truth nonetheless, and is becoming more obvious every day). WPF has a host of features that WinForms will (probably) never be given, such as integrated support amazing data binding, and timeline based animations that make it easy to make amazing themes for your apps, and will have designers begging to make the switch. There is much more to WPF than can ever be described in a comment, but these are two big ones for me :)
This being said, I know there is nothing you can do in WPF that you cannot do in WinForms. You can do anything in any language if you want to badly enough. The point is that where WinForm's will leave you scouring google for how somebody else did something cool, WPF ships with built-in support for all the features that Microsoft considers to be the future of Windows and puts them right at your fingertips.
Over time, people will become used to new features build directly into Windows, and will come to expect them to be available in all the applications they use. This will reach the point where anything that doesn't support them will feel clunky, less usable, and seem less worth spending money on. (I see Touch integration as the most obvious example of this. Although there are touch screen solutions that clamp onto a monitor and emulate a mouse, on any computer, touch screen technology has come a very long way, and with Windows 8 blurring the line between the desktop and mobile devices, people will likely want to use applications in a way that will be exceptionally difficult to implement if your application uses WinForms.)
Sooner or later, I believe that support and development for WinForms will stop, and everybody that left themselves behind will be forced to port, and quickly. However, there are too many programs out there that rely on WinForms for Microsoft to be able to drop it in the near future. Who knows what will happen. Perhaps WinForms will be to Microsoft what Itanium Processors are to Intel, the product that has enough users that to keep it going, even though there are better solutions available. ( http://arstechnica.com/business/news/2011/06/ask-ars-why-itaniumask-ars-with-xeons-improvement-why-bother-with-itanium.ars )
So my advice would be this: regarding new development, make the switch to WPF. Send some staff on training courses, or let them play for a while so they can get a better feel for the technology. The learning curve is going to be steep, but doing this will increase your team's skill set because by learning WPF, they will also be well on their way to learning SilverLight, which is similar enough to WPF for people familiar with WPF to be be able to learn it quickly, but is designed for the web rather than the desktop. This is valuable because apps rewritten in WPF will far easier to convert to Web Apps later down the line. WPF is new, but it was made for a reason, not simply for the sake of making something else for people to learn. It was designed to make applications more user friendly, intuitive, and portable. It was designed to help developers make their applications fit into the new age of computers.
Regarding applications written in WinForms : I think it's safe to assume that WinForms will still be supported for quite a long time simply because of the amount of support it has gained. I would recommend letting your team familiarize themselves with WPF, and slowly start moving your applications over to WPF. Take all the time that Microsoft allows and don't rush the process, but always keep in mind that, one way or another, WinForms day's are over, and although nobody can be sure what will happen, support for the legacy product will be dropped as soon as it can be justified. Even if WinForms applications are kept around for many years, it is important to remember that times are changing, and we all need to change with them.
----EDIT 2 -----
Given that you're trying to make an editor like the one you showed, I'd recommend going WPF even more. My current project has many features along those lines, as well, and we've decided that the ability to composite WPF with Direct3D content is extremely powerful. It's nice to be able to render your scene into anything - not just a rectangular window. In WinForms, you pretty much were limited to one rectangle, and you had issues with airspace there, too (subtle, but things like flickering issues when menus pull over your hwnd, etc). The WPF compositor with D3DImage gets rid of all of those issues, and lets you use your imagination to construct a very flexible UI. Things like rendering your scene in realtime on the side of a WPF3D object are possible, or using WPF controls directly on top of your d3d scene instead of trying to do the GUI in D3D, etc.
-----Original---------
If you're going to be hosting DX, you might want to consider it - especially since it gives you the ability to do scene composition with your UI and no airspace issues if you use D3DImage.
This does work with SlimDX and WPF.
----EDIT-----
For more information on the disadvantages of using Direct3D with Winforms, and the advantages of WPF/DX integration, see:
MSDN Article on Airspace
Codeproject arcticle on intro to D3DImage