WinForms is not simple. There are so many core classes that have counterintuitive edge-cases and overcomplicated behavior, and so many things you'd expect to work by default don't.

Databinding is a complete trainwreck, the Combo-box class is horribly overcomplicated by its double-duty as text-entry and drop-down-list, the DataGridView is a complete beast of leaky abstractions, and the layout engine completely falls apart if somebody alters the DPI unless you obsessively test DPI alterations yourself.

I don't blame Microsoft for any of this - it was 2000 and they were making a wrapper around some terrifying legacy code.

But this thing should have been tossed in the dustbin of history a long time ago.

I believe that no technology is simple on it's own, it all depends to the abstractions that you are used to. Counterintuitive is dependent on how things are expected to work.

Data binding is not solid, but it is a quick hack to display data, the solution is using a business model and mvp or mvc.

What do you find complicated about the combo class?

Data grid view... It is a train wreck, but then again, there is not much need to use it if you have a proper model behind.

The layout engine does sucks... The only alternative I found is to use the dev express layout control. The rumor is that 4.6 solves this.

Win forms is solid and it has very little chance of disappearing. Areas of the screen can be controlled independly, which means ui encapsulation is there... Something not easily done in html.

What a hyperbole of a comment. It really isn't that bad.

Sure. But - serious question - what offering from Microsoft would you replace it with?

I keep using it because I'm used to all its warts and idiosyncracies. So I don't know what properly-supported alternative one should use. I just get annoyed how many brand-new fresh-out-of-college developers I meet that use it. They need something better.

Having used both WPF and Silverlight until 2010 (at which point I abandoned the Microsoft stack altogether) I agree, but I don't think the answer is either of those technologies.

Have you tried building GUI apps in Racket? That's the sort of thing I was wishing for when using either Java or .NET to build Windows GUIs.

I've done some academic intro-to-FP stuff in Racket, but haven't really got my feet wet with a non-toy application in it. So the GUI framework is good?

Yup. I haven't built anything of significance in it (yet) but it's proved really easy to learn, and (again, in my limited experience) rock-solid stable and fast enough:

A trivial example:

  #lang racket
  (require net/url
           racket/gui/base
           racket/sandbox)

  (define (menu-file-exit-click item control)
    (exit 0))

  (define frame
    (new frame% [label "Demo"] [height 480] [width 640]))

  (define menu
    (new menu-bar% [parent frame]))

  (define menu-file
    (new menu% [parent menu] [label "&File"]))

  (define menu-file-exit
    (new menu-item% [parent menu-file] [label "E&xit"] [callback menu-file-exit-click]))

  (send frame show #t)

... is all you need to create a basic GUI app with a File -> Exit menu option. And that really is all there is - no resource compilation, no code-behind, no separate languages for expressing the UI and the actions connected to it.

WinForms is still the easiest way to write desktop software quickly and easily. If you don't need a fancy UI for customer facing work, its a great platform for internal use.

... for some definition of "easiest." Maybe I would agree if you don't need to support a custom look-and-feel (Win32-looking apps don't really fly anymore), responsive layout, high DPI, touch/pen input, system theme colors, accessibility, localization, and haven't learned XAML.

WPF and UWP apps are both far easier.

Win32 is the style that Windows apps are supposed to be and what people expect in a Windows app. What are you talking about? In what way does the win32 look "not fly"?

I've tried to use WPF and it was just a major pain and felt like a mess. There is no impediment to "responsiveness".

Where did you get the idea winforms apps don't follow the system colors?

> Win32 is the style that Windows apps are supposed to be and what people expect in a Windows app.

Maybe in the Windows XP era. None of the built-in apps in Windows 10 look like Win32 apps, apart from legacy stuff that hasn't been ported yet and now looks sorely out of place.

https://msdn.microsoft.com/en-us/library/dn894631.aspx?f=255...

Much of the Windows shell isn't even written in Win32 anymore, it's all UWP (source: I work on the start menu).

Have a look at lazarus (http://www.lazarus-ide.org/). It uses a different language (FreePascal instead of C#), but for me it's much more productive, and the programs written run without any framework and feel much snappier.

The data binding in WPF seemed more powerful to me... enabling MVVM approaches, although I'm sure the same is possible in WinForms as well.

Does WinForms still get love in the new versions of the SDK or is it considered done now?

WinForms is in maintenance mode. The only updates it gets is to make sure it runs on new versions of Windows & maybe some security related updates.

(There still are bugs around, but I think they will not be addressed ever. Fixing those could potentially break existing applications relying on that behaviour.)

I don't know, I've done both (Silverlight MVVM and Winforms) plenty and I prefer the manual approach. Databinding is cool until you have any sort of complexity in your app, and then it becomes unwieldy quickly.

Databinding (and MVVM by extension) is ok only in very simple scenarios. Once you hit some complexity you end up in a world of hurt.

Databinding is not a leaky abstraction ,it's a fucking flood abstraction.

Um, if you're using MVVM, then by definition you should have a clean separation between the properties of your Model, which is part of your domain, and the properties of your View-Model, which is part of your presentation tier and directly tied to a particular View. If you have this, what exactly can be leaked by databinding? The only things you're binding to should be properties of your View-Model.

While that's largely true when dealing with pure business logic, there's a maddeningly large amount of UI logic, and hybrid business/UI logic that becomes really annoying (or outright impossible) to handle in pure MVVM with WPF. Reasons for this include that many user interface properties aren't exposed nicely to allow data-binding.

Probably the most infamous one is that the WPF listview with multiple select enabled doesn't allow you to bind to the collection of selected items. Instead you have to do all sorts of work arounds, that while individually aren't too bad, when put all together, makes all the other hard work you put into doing MVVM on the components that you fully control super frustrating.

> many user interface properties aren't exposed nicely to allow data-binding

You hit the nail on the head with this. This is why I don't like to use WPF outside of writing small utilities.

I've worked on large and complex apps with MVVM in WPF and on the web with Angular, and have not regretted using MVVM for a second.

Databinding is indeed a leaky abstraction, but at the same time it's a very powerful one. I'm willing to learn the inner workings of the binding system to avoid performance pitfalls and other weirdnesses. I'm also willing to continually wrap all sorts of not MVVM-ready components to make them data-binding friendly. When people talk about databinding being a leaky abstraction, what I hear is "I was promised magic and it's not actually magical."

Also - there's many different approaches to how it's done with various tradeoffs. Compiled bindings on Android and the new Windows platforms look interesting, and you should also check out how ReactiveUI approaches it.

In the end though, I've never been able to achieve a satisfactory level of loose coupling, testability, and portability without databinding. Despite the overhead and occasional surprises, it's paid off in spades as far as quality and productivity.

As far as I can tell, it seems to be done.