I have read most of the major threads on WPF vs. WinForms and I find myself stuc
ID: 642679 • Letter: I
Question
I have read most of the major threads on WPF vs. WinForms and I find myself stuck in the unfortunate ambivalence you can fall into when deciding between the tried and true previous tech (Winforms), and it's successor (WPF).
I am a veteran Delphi programmer of many years that is finally making the jump to C#. My fellow Delphi programmers out there will understand that I am excited to know that Anders Hejlsberg, of Delphi fame, was the architect behind C#. I have a strong addiction to Delphi's VCL custom components, especially those involved in making multi-step Wizards and components that act as a container for child components.
With that background, I am hoping that those of you that switched from Delphi to C# can help me with my WinForms vs. WPF decision for writing my initial applications. Note, I am very impatient when coding and things like full fledged auto-complete and proper debugger support can make or break a project for me, including being able to find readily available information on API features and calls and even more so, workarounds for bugs.
The SO threads and comments in the early 2009 date range give me great concern over WPF when it comes to potential frustrations that could mar my C# UI development coding. On the other hand, spending an inordinate amount of time learning an API tech that is, even if it is not abandoned, soon to be replaced (WinForms), is equally troubling and I do find the GPU support in WPF tantalizing.
Hence my ambivalence. Since I haven't learned either tech yet I have a rare opportunity to get a fresh start and not have to face the big "unlearning" curve I've seen people mention in various threads when a WinForms programmer makes the move to WPF. On the other hand, if using WPF will just be too frustrating or have other major negative consequences for an impatient RAD developer like myself, then I'll just stick with WinForms until WPF reaches the same level of support and ease of use. To give you a concrete example into my psychology as a programmer, I used VB and subsequently Delphi to completely avoid altogether the very real pain of coding with MFC, a Windows UI library that many developers suffered through while developing early Windows apps. I have never regretted my luck in avoiding MFC.
It would also be comforting to know if Anders Hejlsberg had a hand in the architecture of WPF and/or WinForms, and if there are any disparities in the creative vision and ease of use embodied in either code base. Finally, for the Delphi programmers again, let me know how much "IDE schock" I'm in for when using WPF as opposed to WinForms, especially when it comes to debugger support. Any job market comments updated for 2011 would be appreciated too.
Explanation / Answer
If you have a Delphi background, you will be disappointed in WinForms. You will try to do things that were easy in the VCL, only to find that they're painfully difficult, or even impossible. WPF will be much less confining.
For example, here are just a few of the WinForms limitations we've run into:
WinForms has nothing that compares to TAction, so if you're used to coding with actions, sharing the same text and icon between a menu item and a toolbar button and a right-click menu, centralizing your enabling logic, and updating the enabled state in the background with OnUpdate... you'll hate WinForms, where you have to do all that the hard and error-prone way.
WinForms' old (.NET 1.0 vintage) MainMenu doesn't support images next to menu items, and the new (introduced in .NET 2.0) MenuStrip is riddled with bugs that Microsoft refuses to fix (because the bugfixes might break backward compatibility).
Many controls, e.g. the TreeView, are woefully underfeatured compared to their VCL counterparts (painfully slow, no owner draw, many customization options missing, etc.)
There's nothing resembling the vibrant community of third-party control developers that you're used to in Delphi. There are quality control libraries out there, but you pay for them -- free offerings like VirtualTreeView just aren't out there for WinForms.
WPF is a little more bare-bones in some respects than WinForms, but it's immensely more extensible.
You want something like TAction? WPF has ICommand, which is just as rich as you're used to (but make sure you read Josh Smith's MVVM article -- normally you have to enable/disable your commands manually when the state changes, but his version automatically fires your enabling code in the background like you're used to with OnUpdate).
You want images on menus? That's built in (and nowhere near as buggy as in WinForms).
WinForms leaves out owner-draw on some important controls, but if you're using WPF instead, you don't need owner-draw -- if you want your TreeView nodes to have black text followed by a blue number in parentheses, you just put it in your DataTemplate and it works, no ugly owner-draw code needed.
You want third-party controls? In many cases, you don't need them, because you can extend what's there in ways WinForms and, yes, VCL developers can only dream about.
WPF has a very steep learning curve, but if you pick up a good book (e.g. "WPF 4 Unleashed"), it'll help get you over the worst of it -- and you'll be glad to work with a framework that won't hold you back the way WinForms will.