38

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.

Improve this question
4
  • 2
    Doesn't WPF have a really bad reputation for poor performance?
    – David Heffernan
    Mar 1, 2011 at 21:44
  • 9
    @David: It does indeed have that reputation, but as usual, the reality isn't quite as bad as the rap. Visual Studio 2010's GUI was re-written in WPF, and on most machines there doesn't appear to be a noticeable speed decrease when compared to VS 2008. @Robert: That being said, my recommendation would very much be in favor of WinForms, especially for a Delphi convert. But I'm a little hesitant to post that as an answer, lest it get downvoted into oblivion. Everyone seems to be hell-bent against it because it's "old" technology, as if that actually meant something.
    – Cody Gray - on strike
    Mar 2, 2011 at 6:49
  • @Cody. Understood. I'm getting some great info with the replies and comments, but I'm hoping for more direct info on WPF and it's debugger support vs. WinForms and some job market info. Answers to my queries posed in those topic areas are still wanting.
    – Robert Oschler
    Mar 2, 2011 at 8:26
  • 1
    @CodyGray: You must be joking. VS2010 is a hundred times slower than VS2008, and so is WPF. Your impression is probably due to the usual programmer’s bias: You only look at the most recent high-end machines, which most normal users don’t have.
    – Timwi
    Aug 16, 2012 at 18:37

10 Answers 10

Reset to default
21

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.

Improve this answer
5
  • 1
    Thanks for the direct Delphi commentary. Any job market comments and any info concerning VS 2010's debugger support for WPF, especially tracing/inspection issues? I'll check out the book you linked to.
    – Robert Oschler
    Mar 2, 2011 at 8:28
  • 1
    Don't know about the job market. As for the debugger, expect frustration if your window's constructor throws an exception, because the debugger will be reluctant to give you a stack trace -- but all you have to do is dig into two levels of InnerException in the debugger's exception-details dialog. And if your bindings don't work, run under the debugger and look in the Output window to see the binding errors. Other than that, I'm not sure what concerns you have. WPF debugs OK in my experience, and MVVM lets you unit test more of your UI logic than you can in WinForms.
    – Joe White
    Mar 5, 2011 at 2:43
  • 6
    Very steep learning curve. You don't so much program in WPF; you ask questions on how to convince WPF to do what you want.
    – Ian Boyd
    Aug 21, 2011 at 3:22
  • Actually, some of the biggest hurdles are about learning to work with a framework that separates responsibilities properly, rather than just having everything blindly derive from TKitchenSink.
    – Joe White
    Aug 22, 2011 at 1:32
  • 1
    Can I have Delphi forms, but keep the C# language? Please?
    – Robert Harvey
    Jan 15, 2014 at 23:53
13

I am usually very surprised with people saying that they didn't had a good experience with WPF. I am a developer who switched from C++/MFC to C#/WinForms to C#/WPF. The transition from WinForms to WPF wasn't a easy one because learning XAML is not very easy but once you get hold of it, it is an awesome technology. I, for one, cannot go back to WinForms. WPF is just awesome.

The other thing which bothers me is how people normally associate WPF with only UI. It is indeed a 100 times better than WinForms in my opinion in ease of UI design, but there are many other reasons you will love to use WPF:

  1. UI, of course.
  2. Bindings. Just plain magic. The most powerful feature after UI. LOB applications benefit from this the most.
  3. Commands.
  4. Separation of concerns. Designers work on design, programmers program.
  5. Attached properties. You can extend functionality of third party controls without source code (although this point can well be part of the first point).
  6. Easy transition to Silverlight (Both web & WP7)

You might not agree with me about the last point as a reason for you to learn WPF, but if you ask me, it is one of the biggest. You learn WPF, you can easily transition to Silverlight. Silverlight is growing big, and it is also an awesome technology.

And the biggest reason is, it is the future. It might be merged with Silverlight but the skills will remain the same.

So, I will strongly advice you to go the WPF way.

Improve this answer
11
  • 1
    I'm not saying that I disagree, but all of those reasons are UI related (though you say that The other thing which bothers me is how people normally associate WPF with only UI)
    – Ed S.
    Mar 1, 2011 at 18:50
  • 1
    +1 because I agree with all your points. I got to pick if I wanted to learn WPF or Winforms, and I choose WPF and have never regretted it. @Ed: I don't see any of those as being strictly UI related except the first one.
    – Rachel
    Mar 1, 2011 at 18:57
  • 1
    @Rachel: Really? Binding is used to update the UI when a property value changes. Separation of concerns in #4 obviously only applies when developing a UI. #5 is all about third party controls. No UI, no controls. #6 is again all about translating to a silverlight UI. Am I missing something?
    – Ed S.
    Mar 1, 2011 at 19:21
  • 3
    I've more or less gone the opposite way: WPF -> WinForms -> C++/MFC. Yeah, I'm a rebel; I swim upstream. I just don't see anything compelling about what WPF brings to the UI. A bunch of awful, non-native looking software is not my idea of "progress". Beyond that, I'm not sure how the design patterns that so many (including this answer) associate with WPF are in any way exclusive to WPF. You can use design patterns in any language or GUI framework. Is the difference simply that if you're not forced to, people won't? The ease of transition to Silverlight is the only compelling reason here.
    – Cody Gray - on strike
    Mar 2, 2011 at 8:31
  • 5
    My first task with a WPF application: drop a toolbar, make it 14 dlus tall. cannot be done. Second task: set form font to match user's font face and size. cannot be done Third step: add items to a listview without binding cannot be done i quit.
    – Ian Boyd
    Aug 21, 2011 at 3:26
5

Clearly WPF is the way to go thinking in the future. Mastering it is hard, but the platform is very well architected and flexible.

A few lines of advice:

  • Start easy: Don't try to implement your first project using only MVVM or fancy animations. Start simple with windows, button and lists.
  • Take advantage of DataBinding.
  • Buy the book WPF Unleashed by Adam Nathan .
Improve this answer
1
  • +1. Practical Answer. Try not to implement your first project using only MVVM or fancy animations
    – Karthik Sreenivasan
    Feb 3, 2012 at 6:56
4

I should first note that I am mostly a asp.net developer, though I have used winforms plenty before. The switch to WPF is not as big as you are making it (imo) after a week or so (40+ hours), most was second nature again.

Anyways I believe Anders Hejlsberg is one of the architects behind WPF, at least according to the publishers of this book->

“As one of the architects behind WPF, Chris Anderson skillfully explains not only the ‘how,’ but also the ‘why.’ This book is an excellent resource for anyone wanting to understand the design principles and best practices of WPF.” –Anders Hejlsberg, technical fellow, Microsoft Corporation

http://www.amazon.com/Essential-Windows-Presentation-Foundation-WPF/dp/0321374479

Improve this answer
5
  • 11
    "As one of the architects behind WPF, Chris Anderson skillfully explains..." suggests that Chris Anderson is one of the architects behind WPF. Anders Hejlsberg is only a "technical fellow" at Microsoft Corporation, according to the quoted text, which thus doesn't prove his involvement in WPF.
    – Andreas Rejbrand
    Mar 1, 2011 at 18:13
  • Ah that could be true, but it does show he respects it!
    – Spooks
    Mar 1, 2011 at 18:29
  • 2
    Or at least that he respects Chris.
    – Bruce McGee
    Mar 1, 2011 at 19:31
  • 1
    Or at least that the PR dept got somebody with reputation to make a comment.
    – quickly_now
    Mar 2, 2011 at 7:34
  • @Andreas; Good joke: only "technical fellow". Not wanting to diminish Chris Anderson - He is a great guy keeping a bit low profile (msdn.microsoft.com/en-us/ff395959 is there, but simplegeek.com hasn't been updated for a long while). Anders Hejlsberg is involved in many .NET things (Technical Fellows have a broad reach), after all he is a framework guy (VCL, WCF, etc - see simple-talk.com/content/article.aspx?article=673 and microsoft.com/presspass/exec/techfellow/Hejlsberg/default.mspx) and there are only few technical fellows...
    – Jeroen Wiert Pluimers
    Mar 7, 2011 at 11:12
2

Winforms is very nearly identical to Delphi development. And, of course, there's a reason for that. Just as the Delphi/Object Pascal object model heavily influenced C#, so the forms system influenced Winforms.

WPF seems to be the direction that things are headed; it's been said that the (gorgeous!) VS2010 UI is WPF-based, unlike previous genereations that were built on Winforms.

If you want to stay in your comfort zone, go with winforms. If you want to get caught up on the latest & greatest, immerse yourself in WPF.

Improve this answer
1
  • 3
    WinForms is what Delphi extends, it's actually very frustrating compared to Delphi. It's more like VB-3 than Delphi, and IME the frutsration level is similar.
    – Мסž
    Mar 2, 2011 at 1:56
2

I am not a Delphi programmer, but yes I have worked on both WinForm (heavily) and WPF (less than moderate). I agree with you to some extent on the frustration level for someone who would be making a switch from WinForm to WPF as I have myself being in that situation, but only until I got used to it. Learn and see how wonderful and flexible with WPF is compare to WinForm. It has heavy learning curve, at least for someone who coming from Delphi background, and not Winform. For you, It's definitely worth moving towards WPF rather than WinForm , and its worth the time.

You may want looking into below links to start with :

Improve this answer
1

I had done some Windows Forms work (mostly on Pocket PCs), plus some other non-.NET environment that used the same principles. When I moved to WPF about three years ago, for the first few months I was swearing at it. Eventually it just "clicked" and I haven't looked back - in fact I'd be bummed if my next project required me to go back to Windows Forms.

The last time Windows Forms was updated was in 2005 (VS 2005.) It's still there but no longer being improved by Microsoft. WPF is the new kid on the block for desktop apps, so if you're going to move to the .NET platform using MS tools, then I'd say it's the safe bet. Some people push Silverlight as a desktop solution, but when I looked at it as a possibility, I found that it had too many limitations (which may make sense in a web context, but not so much on the desktop.)

Bottom line: There's a steep learning curve, and I'm still learning it. But it was all worth it. It's a lot of fun.

Improve this answer
1

If you are going to write new applications from scratch, using WinForms would be a mistake. It is basically dead from an investment perspective. Microsoft will keep it around for a long while, but you won't get any new features, or new support, etc. WPF is the clear direction for desktop applications for the future on the MS platform.

From a career perspective, you are also far better off knowing WPF vs. WinForms. For the same reasons above. Also, you will have a good leg up on learning Silverlight. There is a ton of overlap between those two platforms.

And finally, WPF is just plain more fun. And more powerful.

The learning curve is steeper, I give you that. But it is more rewarding in the end.

Improve this answer
0

One additional consideration that should be mentioned is that there's no plan for WPF support in mono. I realize you did not state any interest in (mono) cross-platform support, but there may be an opportunity for this in your future (if you go with Winforms). Presumably, support for WPF in mono (or similar) will come along.

edit: As the link I provided pointed out, and Gulshan's comment highlighted, Moonlight is an open-source effort led by the mono team to provide cross-platform Silverlight support.

Improve this answer
1
  • But Moonlight is in active development.
    – Gulshan
    Mar 2, 2011 at 6:40
-1

I was excited when I heard about WPF, the idea sounded great, and everything I've seen it in has been beautiful. However, when I came to use it in Visual Studio 2008 (admittedly, a beta) I found it frustrating and quirky to work with in the designer/IDE.

I posted a little info on my blog at the time:
http://blog.dantup.com/2007/08/visual-studio-2008-beta-2-first.html
http://blog.dantup.com/2007/08/wpf-designer-cider-part-2.html

I haven't tried it in 2010, though I have spoken to a few people that have, and it sounds like it's still a little complicated/annoying to get to grips with.

I think your application would undoubtedly look/feel better in WPF, but I also think it'll take you longer to build and you'll bang your head a lot along the way.

Improve this answer
4
  • "I think your application would undoubtedly look/feel better in WPF". Not necessarily - WPF won't save you from writing a shitty UI. I have some examples here (one of which is mine, though that one was just a quick 'n' dirty throwaway app to test some stuff.) If you (and the ones calling the shots, aka $$) are willing to spend the time and effort, you can do some amazing stuff in WPF.
    – MetalMikester
    Mar 1, 2011 at 18:35
  • Fair point. What I meant was that WPF allows you to create a more beautiful app, as you're less constrained by the widgets of Windows. Of course, this could be both a good and bad thing!
    – Danny Tuppeny
    Mar 1, 2011 at 19:26
  • 3
    Definitely a bad thing. WPF has ushered in an era of completely non-native interfaces. Difficult to understand and even more difficult to look at. What one person thinks is beautiful is another person's worst nightmare. Leaving "skinning" to the built-in OS controls is a fantastic way to make everyone happy. Then again, I refuse to use the latest versions of Office because I can't stand the interface. So, you know, get off my lawn and stuff.
    – Cody Gray - on strike
    Mar 2, 2011 at 6:53
  • 1
    I'd say this is a little subjective. I probably wouldn't want my Word Pocessor to break all these rules, but some pieces of software can get away with it. Eg. one of the best WPF samples I remember seeing was the Yahoo one - to me, that's a big improvement on a Windows-widget-based app: blogs.msdn.com/cfs-filesystemfile.ashx/__key/…
    – Danny Tuppeny
    Mar 2, 2011 at 7:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.