Tuesday, July 5, 2011

Why WPF sucks: an overview

I was just reading this article detailing someone's frustrations with WPF, and thought I should add to the chorus.

I agree with Mr. Mitchell, I'm fairly sure I will never like WPF. It has a steep learning curve because it's undiscoverable. WinForms was relatively easy to understand; its most complex feature was data binding. But WPF relies heavily on XAML, a language in which MS somehow expects you to "just know" what to type to get what you want, and when you somehow figure out what to type, half the time it doesn't work and you get a mysterious unhelpful exception (or no exception, but it still doesn't work.)

In WinForms, there was an easy-to-use designer and anything you did was translated to easy-to-understand C# (or VB) code; in fact that was the native representation! XAML, however, can't be translated to anything except BAML, so nobody can easily understand what a piece of XAML does, nor can we step through it in the debugger. To make matters worse, XAML relies heavily on dynamic typing (and even the C# part constantly makes you cast "object"s). This prevents IntelliSense from working very well, thwarts the refactoring tools (ever tried renaming a property that was bound in XAML?), and shifts tons of errors from compile-time to run-time.

In short, WPF programs look pretty, and offer better options for data visualization than WinForms (DataTemplates in ListBoxes are a major improvement), but beyond that they are a huge step in the wrong direction. How could Microsoft think this design was a good idea? If any company but Microsoft or Apple made a GUI architecture that was this difficult to use, no one would want to use it. For my company I started to develop some ideas for a GUI architecture that would have been much leaner and more elegant than WPF, but it looks like I may never write that code. The point is, I have some sense of how a GUI framework should work, and it's not like WPF.

I remember my first WPF app. I had an ItemsControl with a ControlTemplate containing a ScrollViewer with a Grid inside (note the learning curve: you can't use WPF very well without some idea what those terms mean.) I wanted to know: "How do I attach mouse event handlers to an ItemsControl to detect mouse clicks and drags on blank space?" The answer? In order to get mouse events with meaningful mouse coordinates (i.e. coordinates in scrollable space), it was necessary to obtain a reference to the grid using a strange incantation:
Grid grid = (Grid)_itemsControl.Template.FindName("Panel", _itemsControl);
Then I attached event handlers to the grid, and inside the mouse event handlers, get the mouse coordinates w.r.t. the grid using
Point p = e.GetPosition((IInputElement)sender);
Plus, in order to get mouse events on the entire surface, the control (actually the grid) must have a background, so my transparent control still wasn't getting events.

In another case I had to use this incantation:
var r = VisualTreeHelper.HitTest(_panel, new Point(e.X, e.Y));
var hit = r == null ? null : r.VisualHit as FrameworkElement;
In WinForms, pretty much all the methods you need are members of the control class you are using. But this example shows that in WPF, sometimes you have to call a static method of some other class to accomplish what you want. Then consider the minimalist documentation (so that you really need to buy a book to learn WPF)... that's undiscoverability at its finest.

Update: Also, WPF is shockingly inefficient, as you may learn if you need to use a non-virtualized ListBox in order to get MVVM to work and the list has more than about 1000 items. Trivial items (short text strings, no DataTemplate) consume about 8 KB of memory per row, or 80 MB for 10000 items, and ListBox takes 4 seconds to handle a single arrow key pressed in a list with this many items.

93 comments:

Richard Mitchell said...

We had a couple of developers doing a down tools project in WPF who had a similar problem with controls not getting clicks and it was indeed due to it having a transparent background rather than a solid colour. Not something I'd immediately think of.

The other problem I encountered was a rendering problem only on certain graphics cards for certain effects. An example of this can be seen on the MSDN forums.

WPF is a nice idea and the binding allows a much better separation of engine and UI but I would really want much more compile-time checking as the opportunity for run-time breakage is way too high for my old brain.

John Fuex said...

You hit the nail on the head.

Unlike web forms that encourage you to learn the platform incrementally, you will spend the majority of your time in your first WPF project feeling completely helpless and stupid.

Props to you for telling it like it is.

Steve said...

Totally agree with this. I'm on my first WPF project; and while there are some cool aspects to the framework, I've found it *ridiculously* annoying to do the most trivial things. For example -- data binding to a header column of a DataGrid; or adding footers with multiple totals to the bottom of one. I've sent hours trying to do simple things I've done with other frameworks in minutes.

To make matters worse, when you Google "WPF Sucks", this is the first thing that comes up: http://goo.gl/zMon4 -- some poor shmuck trying to learn WPF and being told "no, it doesn't suck," and that it's his fault because he "hasn't grasped some concepts". Well, maybe that's because Microsoft's WPF documentation sucks, too.

Thanks for commiserating with those of us who think WPF is just plain annoying.

Anonymous said...

I started a specialized text-editing app in Winforms, but decided to restart in WPF as it's "The Future", and I should learn it. What better than a simple app to do so? Well, Every Single Thing I tried to do was painful. Everything. I kept saying "it can't POSSIBLY be this hard, all I want to do is..." I'd search for examples of what I could do INTUITIVELY with a couple clicks and a line or two of C# in Winforms, to be invariably hit with "It's simple, you just..." followed by a wall of XAML. Maybe I'm old fashioned, but I want to write the program in the language I'm writing the program in.

I'm new to Windows programming, but I know the basics and can find my way around C#. When I got stuck in Winforms, the problem was usually something simple that I'd remember. But I'm bailing on WPF because I'm sick of using 99% of my time googling to find some arcane XAML incantation to make something simple work. I guess it's great if you're an expert, but experts of any system/language will claim that. It doesn't make it inherently better.

If MS is headed in this direction, then I expect Windows 8 to do everything you'd ever want a GUI to, except it drops you to the command prompt when you need to do simple file operations like copy or delete.

Anonymous said...

Totally Agree. WPF is the worst programming model i have worked with.
It may be a super genius design but if its not practical and usable, its just a waste of time. Microsoft and Adobe (MXML/Flex) just copied each other and both technologies will go down.

I have wasted enough time on WPF. I think i will probably move on to C++/MFC. With Apple Objective C coming up , a bit of C/C++ skill will be good.

Im starting to like Javascript because of XAML :). Atleast I will not be proposing WPF for any new projects in my company. I would rather go with C++/MFC or SVG/HTML5.

Nick Bedford said...

Never a truer word was spoken.

I love Windows Forms development because it allows me to Get The Job Done. I drag a control in; I double click it; I type a piece of code in; I hit Debug and the program looks like it is in the designer, behaves like the rest of Windows, does exactly what I ask of it and this is all finished within minutes of creating a new Form.

I've tried learning to use WPF a few times and it's a total clusterf@!k, excuse the French. Most of your Windows Forms knowledge is completely thrown out of the window. The designer UI doesn't look like anything in particular, the controls have annoying state fades (buttons take more than a second to fade to a hover state), and there's many missing objects that are in Windows Forms.

I also dislike the change from C# generated UI code to XAML. Why? I can adjust UI code directly in the language I already know which has full Intellisense.

WPF is not the future. It's an entirely separate framework for other people.

Anonymous said...

In all honesty, sometimes I feel WPF is a bad MS joke taken too far, kinda like Windows ME where a group of developers came up with an idea (which was really a prank) on how to write the worst possible piece of software and get someone to use it on April 1st. Unfortunately, due to some mismanagement it got put into MS release cyles and before they knew it the software was packaged and put in front of us dumb folks trying to figure out how to make something totally unworkable work. You can't accuse MS for not having sense of humour, that's for sure.

Anonymous said...

WPF = NO VALUE ENGINEERING

Anonymous said...

I want to build a mid-level app. Had a choice of WPF, old schools windows & Java.

Whoever invented WPF needs to be hired by the NSA - I would never be worried about nation's security with that guy in charge of encrypting everything. In any case it would get him away from real-world problems we all face.

Anonymous said...

I can't agree more. In the Xaml, you never know where to put your hands to make things work.

Anonymous said...

I agree with all of the above and then some. And we're not alone. I've done many applications in Java and Win32, I've done many Web-Based apps. I've done exactly 1 application in WPF and am still struggling with. It was also the last one I'm sure.

Marc W said...

I am not sure what to think of WPF yet. But there is one thing that annoys me: The talk about the flashy GUIDs. I am totally not interested in that. I personally hate a GUI with all kinds of bling bling, and no consistent way of presenting and finding information. That is totally not a motivation for me to learn WPF.

The software architect I work with drools with the tool though. But he is a typical MicroSoft one trick pony, that loves everything if it has the mark MS on it.

Ceddy said...

I had the hardest time figuring out how to use a button in WPF. I am an ASP.net guy and I think WPF is way too complicated, especially if you are using the MVVM approach. So many views, so many view models, so many models, any software engineer would get lost. And yeah the learning curve is very deep, too deep if you ask me. I personally dont like it and I dont think it will be around long. Great post.

jlechem said...

I just had to jump on the band wagon here. I've been writing C# since version 1.0 was released and have used winforms extensively.

I've also done C/C++/MFC/QT.

I decided to use WPF since it's THE FUTURE. Talk about a royal PITA. XAML makes layout a bitch and half the controls I could just drop onto a winForm I had to hand craft a shit ton of XAML that often never worked. The learning curve is a cliff. I gave up and will stick to winForms.

XAML and WPF blow.

Qwertie said...

The sad thing is that WinForms really needs a replacement... but WPF and Silverlight don't cut it. I'm really tempted to make my own frickin' modern GUI library... but I haven't used WinRT yet; is it an improvement, or more crappy XAML?

Unknown said...

I agree that out of the box WPF can be complicated and tedious. But I do have to give them credit for creating a very extendable framework. I'm surprised more people haven't taken advantage of that to make it simpler. I was able to create a binding syntax that essentially replaces WPF binding syntax, you can find it here: Simpler WPF Binding - I was just scratching the surface, I think a lot more is possible. I have not seen many efforts like this though, maybe the initial learning curve is just too high to gain enough traction.

Elo said...

I completely agree that the learning curve for WPF, particularly the XAML portion, is quite steep. Once surpassed though (to some degree, I still have MUCH to learn) I find it a LOT more enjoyable and productive for me to work in WPF than WinForms. I do all of my prototyping and personal work in WPF and it just feels comfortable now.

It feels like I have much better control over how the layout will look and function. The separation of data formatting from how the data is represented is really great. What's more is I can see all of this from a single view instead of having to go through property page after property page, or have to read the auto-generated code and work backwards.

On the back end using WPF helps guide me towards writing better code. It goes against the grain to 'cheat' and if you're referring to any GUI object by name then you know you're doing something wrong (98% of the time).

The data-binding is beautiful and very powerful/flexible, and may actually be the best feature of WPF as a whole.

Despite all of this, I do recognize the huge community backlash on WPF. There seems to be even more dislike of WinRT, Metro, and Windows 8. With Microsoft trying more and more to bury WinForms I'm struggling to figure out where to focus my efforts for the most ROI. Silverlight appears to be a dead end road as well. ASP.NET MVC seems to be getting good press of late but who knows on that. Maybe it's time to go C++ with QT?

I don't know, I like WPF a lot, but the ship seems adrift and people are catching life rafts left and right. But where are they headed?

John said...

I was a Software Design Engineer with Microsoft while this WPF POS was being designed. The ONLY reason we are stuck with this SNAFU is it was Eric Rudder's brain child. Eric is one of BillG's inner-circle. No doubt Eric is smart, but he is a complete A-Hole with no common sense.

Pray that BillG does not replace SteveB with Eric. If he does, forget about Windows and figure the rest of your life you will be DEV'ing for OS/X.

AJ said...

Instead of WPF, it should have been named WTF (What the F**k). You get the idea. I thin the idea is great but the implementation is overly complicated.

Sandro Magi said...

I was about to start my first WPF for a client. I had heard it was a little difficult to learn, but figured I might as well learn it. You've just convinced me to avoid it. Winforms + Rx.NET it is, thanks!

Anonymous said...

Thank you for the post and all the comments... I'm glad to not be the only one who gets irritated and google's "WPF sucks" every time I attempt to do something seemingly simple with WPF. It seems WPF is one of those instances where everything is changed for the sake of change rather than any real improvement. Yes, I hear WPF makes this better, and that better, but for what I'm trying to do, it's basically change for the sake of change. Wish I started this project in good ol' WinForms as it would take me a lot of time to change now.

Anonymous said...

I feel like WPF is part of a larger misconception that less code is always better. Look, I did this in three lines of code! Look, I did this in zero lines of code! Well, being able to do lots of stuff with little or no code generally means taking advantage of *implicit* behavior. And specifying things in declarative tree structures (XAML) generally means writing *strings* instead of *code* -- strings that are treated as code implicitly, that specify not only layout but functional relationships, but for which you have no intellisense to guide you and remind you of what's possible and how things work. With implicit behavior, sure, you don't have to spell out the little loops and default relationships because they are taken care of for you by the framework. But that assumes you know how the framework is doing everything -- and there is really no way around having to gain this knowledge because as soon as you want to tweak something you need to know what's really going on. In my opinion/experience, it's much better to have to wire things up yourself a bit each time -- to write those little loops and relationships -- than to have to understand all the implicit rules, relationships, and mostly opaque behavior that let you bypass that code.

Anonymous said...

Yes, I think WPF is very gay indeed.

Specifically the following points:

1. XAML is hideous to work with. The designer is awful and buggy. The designer from VB6, over a decade ago was better!!

2. Everybody wants to use MVVM with it! Why? It's a horrible pattern. As soon as you try to use it for real world applications you end up with ten million viewmodels. The very nature of the view model means replicating the same properties from your model/dto or whatever and then adding in lots of other specific properties to do with how text is displayed on your views. Horrible, really really horrible. Reckon everybody will look back and laugh at what a load of crap WPF/MVVM is.

Funniest thing that makes me laugh is when you see newbies talking about how great MVVM is and then detailing 100 lines of complex code they used to close a view from their viewmodel. Great pattern that, if it makes you replace one line of code with 100. Oh, and at the same time they're all spouting on about how MVVM makes your code so much more testable, you couldn't make it up. Knobbers.

Qwertie said...

Err... although WPF sucks, I do like MVVM, and viewmodels are easier for automated testing than views (although so far, not easy enough that I've been willing to take the time to actually do it.) I am even using MVVM with WinForms+UpdateControls, although it is a bit clunkier.

Anonymous said...

Thing is though, have you or anybody ever seen one of these viewmodel tests? Nope. Never seen one. Any who cares anyway! Most of the business logic, the stuff that needs to be tested, is in another layer that's always been testable - and even that stuff only gets tests written for it 50% of the time.

In the real world people don't have time to write many tests so they write them for the important stuff - that's not stuff in viewmodels.

So, the fact that the ability to test viewmodels is one, if not the, most important factor continually mentioned by MVVM enthusiasts, and yet it's so important nobody ever uses this important factor, tells us something very profound; MVVM is crap.

The only place I have seen where I have chosen to use MVVM is for building stuff like TreeViews. These are much easier to use where you bind to and manipulate viewmodels (possibly listviews as well). Everything else, MVVM gets in the way for no benefit.

I lika, to do, da chacha.

Anonymous said...

What amazes me is the popularity it gained. Everybody is talking about WPF and MVVM, while it is really such a pain in the ass. Just look at the staggering number of questions asked in forums such as StackOveflow to gain some understanding as to the complexity of WPF. I mean those people who asked those questions are not dumbs, nevertheless, many of them lost hair due to them so many times banging into the WPF wall. its popularity is definitely beyond of my comprehension.

Anonymous said...

I've been working on a project for 3.5 years now. It's a desktop app with WPF and Winforms, about 600,000 SLOCs. I made the mistake of using WPF to get some of the transparency features, and animation. Hey, some of that stuff looks nice. However, every time I try to do anything beyond simple - I wind up spending hours trying to get it to work. I spent 3 hours yesterday trying to make a datagrid embedded combobox work with a lookup table. Jeez - it was like beating myself in the head with a hammer. MS had better get their stuff together quickly. That is all I know. I'm glad I'm almost at retirement age. I still remember Turbo Pascal. LOL

alexpchung said...

WPF makes me want to cut myself. I hate Microsoft WPF.

Anonymous said...

My project now contains over 42,000,000,000 viewmodels; some of them have unpronounceable names as I ran out of words in the English language.

Who invented MVVM/WPF anyway? What is his name? Is is still alive? Why is he still alive?

Anonymous said...

Hey everybody, I've got a great idea. Why don't we all use a pattern where I have to copy everything I need from my window (view), like say, the index of the selected item in a dropdown, to another class. Instead of then writing code to act directly on that index in the class commonly known as the 'codebehind', I'll copy it to another class via some manky databinding and then manipulate it there. Er, good idea. I'll end up with ten million properties.

Who was actually barking enough to think this was a good pattern and why the hell did then entire IT industry act like a bunch of retarded lemmings and jump in there?

Qwertie said...

I do like MVVM, actually. Not the "perfectionist" flavor in which there has to be a series of properties (Foo1, Foo2, Foo3...) in the viewmodel that are simple wrappers around the existing properties (Foo1, Foo2, Foo3...) in the model; I do not like to waste my time. When I use MVVM, viewmodels are not allowed to access the view and models are not allowed to access viewmodels, but the view can directly access the model if the viewmodel does not add any additional functionality.

Back when I put all my code directly in the view (WinForms), it was a big mess. By using MVVM with Update Controls I get two benefits: (1) code that is more organized, and (2) automatic data propagation from the model to the view. If two views show different representations of the same data, they are automatically synchronized. If the model is modified, whether by the GUI or by code outside the GUI, the GUI is updated.

Note that MVVM is not WPF-specific, it just happens to work fairly well in WPF, most of the time.

Telavian said...

I have been using WPF for a few years now and I am amazingly more productive than I ever was in WinForms. WPF feels much more natural and smooth. I think all the dislike is essentially because it is a new technology with a new way of doing things. WPF is vastly better than WinForms and is far easier than Asp.Net.

Anonymous said...

Have to say that I don't think people dislike is because it's a new technology; it isn't any more, it's been around a long time now. I've been in IT a long time. I've spent years doing WinForms, years doing ASP.NET and years doing WPF. They've all got good and bad points, it's just that WPF has a lot more bad points than the rest.

The only think I like about WPF is how powerful and flexible it is in terms of designing screens to look and behave exactly how you want. Everything else is dreadful. I find it far, far slower to develop in than WinForms and certainly far messier and frustrating.

I think the fact so many people dislike it and find it a pain says something about it.

Anonymous said...

WPF is vastly an incomplete piece of technology.
When you release a "new" paradigm, that is supposed to be "the future", you have AT LEAST to guarantee that *everything* you made with the previuos tech, is doable in a easier manner. Plus, you must add some strong new points for the new tech.
This simply doesn't happen with WPF.

Microsoft completely failed here, and it is failing miserably in all the area of smartphone, tablet, desktop.

Even in the web area, the marketing is completely wrong: everybody can recognize that MVC is "the way to make web app today", but still MS says "it depends". LOOOL
MS even developed a mixed enviroinment called Webmatrix, where you got Razor server syntax BUT a page model (like in classic asp). This is soooo evil. Sooo much confusion for developers!

Steve Jobs clearly teched us that a company CEO must indicate what is past, what is present and what is the future.
Jobs made the funeral to System 9, when he introduced OSX, to clearly state that OS X = future, and System 9 = dead.

MS *never* says "this is dead", and that is a total failure, I'm sorry but this is for real.

MS is a slow bandwagon of geez, always late on technology, completely fail the smarthpone tablet, MS will be irrelevant in the Market with Lumia covering a ridiculous 2% of the market after 3 years.
Win8 is a fail.
What we will have within 6 months? Win8.1?? ahaha still the same crap.
While competitors are miles ahead.

Anonymous said...

I love you guys!!! I have been banging my head against a wall for days now saying "Surely to cr*p it cant be this hard to do a combobox or a listview"....but it is. Is this a joke? Twenty years of programming exp, web, winforms, C++ and yet I am stumped by this dang awful cryptic BS called XAML. MS pull your head out of your a double five (a55) you keep this up and I am no longer an MS primary programmer. I will go PHP Jave anything but XAML.

Anonymous said...

Great comments, personally I cannot stand all this MVVM BS, patterns that over complicate simply are a waste of time I do not care how well you know it. Reusable code phaff thats been the holy grail for decades are we so conceited to believe that what we write today will be relevant never mind five years from now how about 6 months. All apps should be built as quickly and simply as possible to aid in maintenance full stop, they will be in the bin within 3-5 yrs and everyone will mock the technology being used..As someone else said and all the lemmings just jumped on the band wagon...what happened to web services...then what happened to WCF and now windows services...please give me a break. No prosetilising its all BS C++ seems to be the one stable language.

Anonymous said...

Pretty naive comments here from developers who don't know how to use the product.

Native controls are written around the MVVM pattern, what's so hard to get your head around, don't get confused between the pattern and some of the bloated frameworks out there.

MVVM Light will take care of most of your VM wiring leaving you with a testable VM decoupled from your interface which can then be styled in blend.

WPF can be challenging especially as you probably have to use IoC and Prism if you want modularity but the upside, it's also challenging if your thick!

Anonymous said...

" I find it far, far slower to develop in than WinForms and certainly far messier and frustrating."

VS2010 and 2012 are written in WPF btw.

Winforms is dead, it's is easier to develop front ends if you want something basic, invest a little time into learning WPF, you won't get it straight away. Feel free to stick with a toolset that hasn't changed since 2005 though, just don't expect to pick up a decent contract/job in 5 years time.

Ian said...

I first built GUIs with Borland's OWL and Microsoft's MFC. Using either of these to put together a LOB application was so much easier than with WPF. MFC had a wizard that built a basic but working app to start with. WPF gives nothing like that. Also, Microsoft provided many complete sample applications. Life was so much easier then. WPF is a big backward step in terms of usability.

Anonymous said...

Pretty naive comments here from developers who don't know how to use the product.

Native controls are written around the MVVM pattern, what's so hard to get your head around, don't get confused between the pattern and some of the bloated frameworks out there.

MVVM Light will take care of most of your VM wiring leaving you with a testable VM decoupled from your interface which can then be styled in blend.

WPF can be challenging especially as you probably have to use IoC and Prism if you want modularity but the upside, it's also challenging if your thick!


Lol, everybody else is thick. I can assure you that I understand fully how to use WPF, MVVM etc. I also fully understand how to use many other technologies so I can compare and contrast accurately. WPF is sh1t, complete sh1t for all the reasons elaborated above. MVVM adds greatly to the sh1tness for many other reasons.

There's nothing challenging about IoC etc. It's WPF/MVVM that's challenging because they are so painful.

You sound like a junior bod who doesn't really know much about anything and so have nothing to compare to. You are also very arrogant in assuming that many other experienced developers are all thick rather than have valid points.

I put it to you that you are actually the Mr Thicky Junior here and your code would probably make a monkey burst out laughing. Thicky dumbo.

Anonymous said...

I hate WPF too. Shelling out the money for Microsoft products was always ok because their products made things easier. WPF is too hard to learn for guys like me who just want to painlessly create little apps.

Anonymous said...

What's the best part of programming WPF/XAML...when you're done programming WPF/XAML.

Anonymous said...

iv told to my self many times. Go ahead give it a try , give the chance to WPF to win you. every day am fighting with my self and WPF but i always get the WIN :) i don't know why.. m('.')m
There so many difficulties that makes me hitting my head.

Many users are finding wpf much more easier and am trying to understand what they found easy rather than the GUI where you can make it look nice, but after all even that you realized that at the end you spend hours in design to adjust the controls to fill the correct size ,locations ,layouts panels etc.. and all that using XAML not in designer because you realized that the Designer is not really helpful at the end. For someone like me coming From Windows Forms i find it extremely difficult this learning curve.

As someone mentioned, definitely windows forms need improvements but of course this not with WPF.

I wondered how long wpf will be on. and what Microsoft says about all that feedbacks,
I hope to see something new in windowsForms that will really be helpful and stable improvements

Anonymous said...

There is a learning curve, but once you learn it WPF is pretty cool. XAML is a great way to do layout, data binding is flexible, and you can build large, reliable, modular projects with it.

Unknown said...

Some criticise those who say WPF is too hard. It's wrong to do that. The fact is that building a GUI app used to be so much easier. Why bring out a new technology that makes it harder to produce a GUI than it was 15 years ago? There is no benefit. .NET has been a huge mistake.

Anonymous said...

I agree with these posts . . . that is why I wrote an open-source code library that allows you to write a WPF app with NO XAML at all. 100% code-behind. This library is very late to the party, but it makes building WPF apps much more fun. Very good for building small WPF tools fast :-)

http://wpfcomposites.codeplex.com/

Enjoy,
Bryan

Anonymous said...

Hmmmm... I was in love with WPF once. That was until I had to bind a group of radio buttons to an enum. Sure it's possible, but if I have to write extra 40 lines of code to find out which radio button was checked then I know there is something seriously wrong with framework.

Anonymous said...

I think WPF is a great framework for bling bling prototype and projects that user-experience is rated much higher than development/maintenance cost. This is 2014, and in terms of user-experience per dollar, winform still wins hands down.

Anonymous said...

WPF is stupidly difficult. It used to be the case that simple GUI's could be produced with very little thought and they were much much faster than anything you can do with .NET let alone WPF. C# is a pain the ass. When I delete a C++ object it's gone and the destructor is called immediately. .NET is a lumbering giant and WPF is a product of warped mind. C++ with ATL/MFC was fast and sleek.

Anonymous said...

well, the only think I can say for WPF is that I want to scratch my face front of the screen, then sit back smoke a cigarette and then go back to windowsForms
:asda grrrrr!!!

Anonymous said...

I read all the comments and I could not notice that there are some people who are still trying to explain how good WPF is (although they are obviously at the wrong place, I mean WPF sucks gathers people that hate WPF...).

Those people compare it to WinForms and say "well, it is clearly better than WinForms; why don't you invest some time and learn this "new" technology...". Sure, it is better. Especially since WinForms is dead. I mean a living dog is better than a dead one.

But that is not the main problem with WPF. The main problem with WPF is that it is not simple. And here should be made a clear distinction between easy and simple. Easy means well known or similar, close to the existing knowledge. Easy is relative. One thing may be easy for you, while incredibly hard for others (say Chinese). Simple at the other hand means obvious. It means decoupled. Simplicity hepls you reason about your programs. (Some things are decoupled in WPF, say UI and logic, but not all. Furthermore things in WPF are not obvious.)

It is easy to speak German if you are German. The same thing goes for WPF. It is easy to take advantage of all the goodies provided once you grasp the "whole concept".

In WPF MVVM is not the problem. Nor is the pages cluttered with code. Neither is the hard debugging. The problem is that WPF is a ridicoulously complex framework for what it does.

And I am telling you this not as some random guy. I am telling you this after years of writing PHP, Pascal, Java, SQL, C/C++, C#, VBScript, JavaScript, HTML, CSS, XAML (yes, XAML, for both WPF and Silverlight, 3+ years of experience), Python, Clojure. I am not even going to list technologies such as Swing, WebForms, WinForms, MVC (as ASP.NET MVC) etc. There exist far better options in other frameworks and languages simply because they are SIMPLER. And by the way Swing and WebForms are not much simpler.

Frameworks should be simple. WPF is not. Complexity is not a challenge that the developer has to tackle. Complexity is something that the creators of a framework should consider and prevent. Everything should be made as simple as possible, but not simpler of course. After all Einstein said it: "Any intelligent fool can make things bigger, more COMPLEX, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."

Anonymous said...

WPF is the greatest tool for creating complex UI if you are experienced enough. I had to learn a lot when i started 3 years ago and now i am still on the road of getting it.
Complex UI is complex in nature so if you seek for simple programming, go doing foxpro, excel macros building or at least Turbo Pascal on old mainframes is for you.
WPF is tough to learn but i repeat it's because the nature of the problem it solves.
Try to apply your WinForms in the project where non standart design required and you'll find it's implementation more difficult and time consuming than learning WPF + solving the problem.

tex said...

What hasn't been mentioned yet is the fact, that the tooling support of WPF is one significant weakness.
The designers (Blend, Cider) are so unstable, that I encounter constant crashes of Expression Blend 4 or Visual Studio 2010/2012, although they are really meant to be used simultaneously.
Adding the buggy behavior of caching stale error messages I often tend to get lost while searching for the real error cause.
So, all in all, even provided, WPF would be a nice framework, it is a real pain in daily work, as Microsoft failed to provide a stable development environment, that could cope with the added complexity, which by itself is a strong hint, that WPF is too clumsy to be such a great advantage regarding productivity.

Old and Pissed said...

WPF is a horrible excuse for a UI design paradigm. Those who say otherwise just have not spent much time doing enterprise worthy Windows applications. Anyone that has used a capable UI language (like VB6 was) knows that WPF and other MS products for developing UI's are a major step backward.

Avnesh said...

WPF is most worse UI framework I ever worked on.
From UI development point of view, in terms of simplicity and speed, does anyone know if Microsoft ever produced anything better than VB6 ?
I am in middle of a WPF project, a serious real life LOB, and don't know how to complete it in WPF or restart it in WinForm. Can anybody help?

Unknown said...

For people who are praising WPF and mention feeling comfortable with it, something helpful would be a review of how you learned it?

For anyone that would say they now feel comfortable with WPF, what are some good paths to learn it coming from Winforms? I don't even know where to begin, myself. I have lots of bits and pieces, even some success (and frustration) with a WPF project of my own. I don't know what a view or a model or a viewmodel are, so it's more of the learning 'cliff' that I can't read about WPF without finding that I need to learn what I didn't know I don't know to learn what I want to know.

Anonymous said...

Sad thing is we have 2015 and WPF is still around.

PG said...

Sad thing is we have 2015 and WPF is still around.

No. Sad thing is that it still has fanatics

Gino said...

Could you imagine being a programmer in another language, or worse, a non-programmer trying to learn programming for a job assignment, who has to not only learn C#... but learn the whole WPF/XAML mess needed to write the application desired.

I'm just such one developer who has never programmed in C#, nor .NET, nor WPF/XAML... no, I'm a C++ developer who uses Qt to build his interfaces and quite enjoys it because of how productive he can be in a short time period. I've been programming for years, I don't have years to master not one, but two new languages, one of which is hopelessly verbose and complex not to mention cryptic as the zodiac killer's ciphers to police.

I have a feeling that, in WPF/XAML, the interface alone is going to be 90% of my developer time and then when I'm done learning and using all that to write the UI, I still have the actual functionality to learn how to write and dig through .net documentation to figure out. And I've never seen a programming book as thick as the Pro WPF 4.5 in C# book. The newest edition of Professional C++ by wrox is actually thinner than the second edition and not only covers C++11 but C++14. It clocks in at 861 normal thickness pages before the index and appendicies. C# 5.0 in a nutshell is smaller than the WPF book at 1009 regular thickness pages aside from the index.

Pro WPF 4.5 in C# Fourth Edition by APress tops them all however at 1040 regular thickness pages and along it's other dimensions is 1.5" wider and .5" taller.

I'm on page 34 towards the beginning of the chapter on XAML.

Needless to say... FML!

Anonymous said...

My biggest pain with WPF is the designer. Once you dare to create a custom UserControl and use it inside another UIElement (like a window or another user control), the designer becomes completely freakin useless, claiming that your markup is invalid and refusing to render anything. I've tried a number of things to fix this, and NOTHING WORKS. What good is a designer that doesn't allow you to visually design?

Anonymous said...

I truly love C#. I think it's the best language so far.

But I really dislike WPF.
WinForms is so intuitive + there is a WYSIWYG editor for it that rocks.
The Xaml editor sometimes shows you the component that you're working on. But I quickly gave up trying to drag and drop anything there with the mouse.
What really annoys me is that there are a lot of really simple things that feel like you should be able to achieve them with a line or two (e.g.: automatically order items in a datagrid by one of the columns). I search for a solution on StackOverlow and I can't believe my eyes. I can't believe the voodoo rituals you have to do just to achieve such a simple thing that should be as simple as switching a property to "true".

I once needed to put password boxes into a datagrid column using MVVM... *sigh*

Anonymous said...

Eh, coming from web development with HTML XAML is very intuitive. Object templates act like CSS, and the layouts are predictable. I'm very much a fan of WPF, and find WinForms tedious at best. Every time I open the editor, it will insist on moving everything by one or two pixels without even prompting me.

Quite honestly, y'all need to get out of the mindset of a GUI as part of your code, that's the first mistake I keep seeing in these comments. The XAML defines a LAYOUT, and forces you to put business logic somewhere sensible. While there are a few things I loathe about WPF (god help you if you need to traverse the display tree), for GUIs that are naturally complex it's far superior to WinForms.

PS: Stockholm syndrome in the .NET world is alive and well, MSBuild sucks in comparison to Maven and Gradle when using Java. C# is nice, its ecosystem is not.

Anonymous said...

The comments here shock me. Are all of you really experienced software/GUI developers? I've done it all in GUI's. I used a lot of existing frameworks out there and I've written my own in web and DX/OGL. I can assure all of you, WPF is the pinnacle of GUI frameworks. It is so ricidulously complete that it is hard to wrap your head around it. I agree that it is daunting, I agree that it is hard. But we're professional software developers for Pete's sake. People expect an above average level of intellect and commitment from us.

I get that WPF hides too much for most C/C++ purists (like myself). But anybody who's done complex GUI's will have to concede that GC languages are more suited for the task.
I get that WPF is too complex for most scripters out there. But GUI's being easy is a myth. It combines complex design patterns, and expects those design patterns to be followed through all the way (not half baked). Again, not what most scripters or drag-and-droppers are used to. Expect to dive into the API old skool style when using WPF.

I'm not here to tell people that they're stupid for not getting WPF and XAML. But I will say that you're all missing the point. GUI frameworks are not about drag-and-dropping your screen together. GUI's are meant to be experimented with, evaluated and redeveloped. The world we live in nowadays require GUI's to handle desktop, tablets and mobile devices. We want rich user experiences. WinForms simply doesn't cut it anymore. Google did it incredibly right with how Android handles GUI's. And Microsoft is even more ahead of things with how WPF does it.

Stick with it, you'll love it. I can already see other frameworks trying to emulate WPF.

Anonymous said...

WPF certainly sucks.

Someone claims that WPF makes you write better code. This statement is not completely right. First of all, dirty or clean, to get the job done is the first priority; Second of all, get the job done quicker is the second priority; better code and better testability is a plus. That's the industry. Tons of code doesn't need tests or super implementation, or super UI. Even with Windows Form, you can write super code, or implement separations just like MVVM does.

The most step back for WPF is not of its steep learning curve, in my opinion, it is the loss of strong typing, that is, compile-time support. I am curious why MS will not re-implement a new "Windows Form" (to go mobile) following the same mindset.

Everyone heard the claim: WPF is the future. I am thinking, if WPF had come earlier than Windows Form, these guys may scream again: Windows Form is the future, because of WYSWYG, efficiency, ...., you name it.

I think WPF has no future. I may be stupid, and will not go with WPF anyway.

Anonymous said...

It was really good to read the comments.. I was getting really disappointed, could not solve relatively simple problems. :/

Anonymous said...

Well personally I love it, self taught no books, it feels pretty intuitive to me, I like how you can do so much more graphically when trying to visualise your data model, things I would never bother to (or would of even thought up) in forms.

From the other comments, it feels like most new users are trying to use it like they used forms (which I did at first too). Separate it out, follow a pattern like MVVM and you'll be golden. Maybe the real problem is long held ideas and design patterns that just don't work like you expect with WPF.

To each their own though, if you don't like it, use something else.

Abel Ruiz said...

I'm not a professional developer but I had some experience developing simple text games and such.

Well, I tried to switch from WebForms to WPF because of two functionalities: seamless image transparency and pretty controls that scale much better thanks to the ViewBox control (good for a game, right?).

And then I discovered that I can't update a simple TextBox without resourcing to threading and background workers... something that WebForms did without any hassle. And this is only an example of how a simple thing gets horribly complex in WPF.

I don't have a doubt that WPF must have a lot of potential for a pro, but I can't invest more than a few hours a day to make games and the last thing I want is to lose them trying to understand how Microsoft wants me to do simple tasks instead of focusing on making them the 'old fashioned' way.

I suppose I'm too old for this. xD

Qwertie said...

Strange. 'Nibbler' wrote a fantastic comment 19 hours ago and it's gone now.

Unknown said...

I have tried multiple times to realist Nibbler's very useful review. It is deleted almost instantaneously. Maybe it was too long?

If anyone wants a copy, I can try again, but I have more important things to do now than fight with what or who is bent on removing it. I will say, the mystery itself is raher compelling!

Qwertie said...

Amazing. As the sole author of this blog, I can't explain it. I can only assume the text itself (as opposed to the author) is being flagged as spam. Which is ironic because it seems like I have to remove _actual_ spam manually on a regular basis.

Qwertie said...

Here is Nibbler's very useful review (again). Let's see if blog authors are immune from the disappearing act.

«Interesting to see this discussion evolving over many years. Summing up my 10 years of experiences with WPF in real-life projects I came to the conclusion that one thing harmed WPF the most: They never finished it really. It somehow just stopped to evolve after .Net 3.5:

Basic things like the famous INotifiyPropertyChanged never got any help from the framework. Yes, it is easy to make a base class for view models handling this. Or to use one of the many frameworks providing something similar. But this harms maintainability when team members change. Having a common implementation in the framework for something the whole WPF data binding is based on would (have)help(ed) much.

What I never understood was how MSFT came to the conclusion to base INotifiyPropertyChanged on stringified member names. No compile time checks for names nor types. In the better case, WPF throws an exception deep inside its inner workings needing a lot of WPF experience to debug and fix. In the worst case, the binding just silently fails. And everything in between. It took until VS2015 to get some binding debug helpers and until .Net 4.5 to get something like [CallingMemberName] and finally .Net 6 for nameof().

Lots and lots of boilerplate code for key framework elements: Take a look at the code to implement one single DependancyProperty. Or the amount of code needed to write a simple ValueConverter (not to speak about type safety).

There is still no decent way integrated into WPF for localization. The MSFT locBAML is a lame joke, and yes, there are 3rd party solutions. But how does it come such a key feature is still no present in WPF?

The visual UI editors always sucked: Beside the well-known stability problems, they all produce unusable XAML with much to many nested stuff resulting in slow views. Fast and stable XAML still needs to be written manually.

And of course performance: At many occasions, the large parts of the visual tree is rebuilt without any apparent reason. Data-binding often queries for many or even all properties of a view model. Also if only one has been changed and notified. List and grid views still lack performance even in virtual mode. WPF is still tied to DirectX 9, which is deprecated since many years.

So IMO WPF was just stooped in mid of its evolution and turned into an unloved step child of MSFT. Not one of the things they promised (WPF local, DirectX10/11, HighDPI ...) was delivered. Just take a look at the embarrassing thing they called "roadmap" in the WPF team blog.

But still: For the data driven LOB application, were you fetch data from some source, present it to the user, let him edit some properties, apply some business logic to it and write it back, WPF is a good tool.
Bit if you want to create advanced UI, you end up with a lot of boiler plate code to achieve simple things. Ever tried to let the user create, select, move and edit graphical elements in an canvas using WPF with MVVM? It was not the first time for me doing this, just the first time trying it with WPF. And I constantly felt I was doing something wrong, because I had to write almost a framework to achieve this and it still was dead slow. And don't get me started about printing.

All the early WPF demos and example were about fancy styled Windows and rotating and jumping UI controls. But somehow many real life problems never were really addressed by the WPF framework.»

Anonymous said...

So true. I am working on WPF datagrid, to simply set its cell value, also cant find some default function to use. What comes in my mind is it is so sucks! At the end, i google WPF is sucks and it comes out this blog.

Janek1731 said...

Years ago, WPF still sucks, ahh nth more really frustrating. Time to move to Android or any other better environments. MS, please do sth with it!
I'm a fun of C# and what I can do is writing some games in Unity and ASP.Net websites, back end is actually quite nice, so I can do this either.

Never mind, please give us some option - fix WPF or create sth new - simple, so simple like WinForms with some Graphics Cards support.

Thanks.

Unknown said...

could not agree more. crappy implementation, crappier documentation, terrible designer, poor performance, difficult to debug and blows up easily a single simple window into tens of separate classes. I describe it as a step in right direction done in a wrong way.

jb said...

WPF has a stockholm syndrome hold on developers because we hate it but we're forced to like it because we need to eat and we're stubborn and think 'well hey i'm smart I can do this oh god I hate my life maybe I'll open up a fish hatchery"

It will take years of therapy to recognize we liked garbage because we were forced to because what else can we do? Someone said it best: a live dog is better than a dead one, and I guess I agree if you're forced to own a dog. Props for everyone telling it like it is.

Now if you'll excuse me, I have to figure out why my databinding is silently failing and why an incorrect image path in my xalm with inscrutable syntax is causing my application to go into a deadlock at runtime forcing me to kill the process.

Dan Howard said...

Spend a weekend with JavaFX. Seriously a breath of fresh air.

Anonymous said...

I have to type in "WPF" or "MVVM" followed by "sucks" once in a while to realize I'm not alone in this world (although marketing types will insist these terms are the greatest ever).

From my experience, I can say that WPF and by extension, MVVM, are cost/time sinks.

It's all good for the fanboys to talk about how they can make pretty UIs. Hell, one idiot even said non-"standart". Yes, let's make non standard UIs; I too would love to lose customers because of my "art". Haven't early 2000's flash websites taught us anything?

It's wonderful that we can make decoupled testable modules... except, well, I always could (and did) make testable modules - in places where it matters, and protip: that ain't the view model.

It's also great that I can use a completely separate application to do my UI design... except, well, it's not. It breaks my workflow completely. Sure, I can use the built-in designer (and... sadly, I do). But I don't think my poor heart can withstand the strain anymore from the rage that thing induces in me when it crashes inexplicably for the 1000th time in a day. It's a festering pile of sh*t.

I'll leave with an example from my job:
Several months back we wrote 2 applications. The first, written completely in WPF, using MVVM, took months to get up to a usable state. The second, started much later, with only a month of development in Winforms was almost totally complete, functional, and much more stable (and the code, while being poorly written, still made 1000x more sense to read).

I'm sure someone will point out: "But I bet the winforms app was ugly/inflexible/etc..." And to that, I say you're a moron. Both apps looked nearly identical thanks to 3rd party components used in both the WPF & Winforms applications - they had to, consistency was key. I say "nearly" because upon review, the Winforms app actually looked much better under close scrutiny. Not only did it look better, it actually did things better like proper visual cues when things needed to be disabled due to a lack of prerequisite data, proper busy state signalling. Why? Well, it was just so much easier to implement in Winforms.

Performance wise, the winforms app just blew away the WPF app. For something that relies on the GPU for rendering... it's awful, especially under RDP/Citrix (which, many of our clients use). For example, we had a pop-up in the WPF app that had a simple text box. I saw the guy hit a key, and about 2 seconds later the letter appeared. That's how slow it was. A similar dialog in the Winforms app was instant.

And finally: The WPF app is still in development (at version 1), while the other app was finished ages back, and is now getting its 2nd round of revisions for the upcoming version.

Oh, and I almost forgot this part: The Winforms app was refactored during this time to clean up the code, and to make it more "MVVM" like with manual bindings and such just because we could.

This whole experience has left me with a sour taste in my mouth for WPF/MVVM. I've found it has caused code quality to really plummet (anyone who says it enforces good quality is utterly clueless), and it's a major pain to do some pretty simple things in it sometimes, which wastes valuable time.

On the next go-around, I will probably be recommending we drop WPF/MVVM. What we'll replace it with (not necessarily winforms)? I don't know, but WPF/MVVM has cost us too much already.

Anonymous said...

Stay away, you want to remain sane. Honestly. It's like Crystal Reports - everyone hates using it, but there's no real alternative.

Anonymous said...

So browsing through all these comments, long story short: WPF is not for below average software engineers. To me that's not necessarily a bad thing. Why on earth would you need more than 1000 items non-virtualized? Makes me think you're not really thinking of what you're doing.

WPF is a peek in the mind of some very smart people who tried to tackle the problems GUIs throw at us engineers. And it is by far the best attempt to unify the best solutions to those problems.

If your application does not need its power, you can always use Qt.

Damian Szczepański said...

I suppose all the languages and libraries (scripts as well) should give you at first, safe against all the problems of the usual languages issues like NPE, runtime exceptions: stackoverflow, indexoutofbounds, etc. and any other runtime issues which is really unpredictable and could cause on end user the impression that your app is crashing all the time.
Predict the problems on the compile time! This is the most important thing.
That's my opinion. WPF is far far away from this, unfortunately.

Chris said...

For all those insisting WPF is intelligently architected, I ask you this. The progenitors of OO never intended for single inheritance (look it up). The fact that MSFT is building UIs with a single inheritance object model speaks volumes to their myopia and (lack of) "smarts". Crafting hacks like dependency properties and other such nonsense to simulate mixins, to get around a brain-damage type system is microsoft's modus operandi (i've been at this since VB6.0 circa 1998 and I haven't seen them change their approach since).

Javascript, with all its flaws, is so popular (i cringe at hearing myself say this) because it gets out of your way. It is ideologically and morally (yes morally) superior.

- Every object can be modified including builtin.
- Functions are first class citizens (no delegate nonsense)
- Closures (adhoc classes) are ubiquitous. State can be passed around organically with no limitations.
- Mixins/mulitple inheritance is easy and a consequence of the elegance of the design
- It's accessible: installing a browser is way easier/less proprietary than installing/learning VS.
- No compilation, just hit refresh
- Persistable: save the webpage and reload whatever HTML u want out of it and (the majority of) your state is preserved no clumsy/noisy ISerializable or DataContracts needed.
- Microsoft's hands weren't all over it to neuter it to the point where it can't compete with their own (what were closed source) proprietary frameworks. Now they've decided they're open source, but it's too late, the closedness of the design reeks all over. The indoctrination is palpable.

The problem with WPF is high intelligent (debatable) but ideologically misguided people are working like dogs to hack around the brokenness of the initial design of.net.

Again I bring us back to einsteins simplicity. Elegant designs take simple concepts and combine them to create powerful abstractions. Simplicity is hard (because you can't just crank out half-baked ideas. You need to think carefully first). The OO system C#/Java use was crippled out of the gates circa 2002. It stayed crippled and millions of poor coder monkeys got sucked into its bible-thumping paradigms that none of the creators of OO intended.

I leave you with this thought. Let's say I have the base class Object (in my poor-man's single inheritance bizzaro-world). The gods of the framework say everything derives from object. And I believe them. I then try to add a field to every object called ID because I want to identify my objects. Fine. Somebody passes me a framework object. Darn it has no ID. How do I fix this? Well I could steal the .net source code (i'm back in 2004), labor to understand enough of the framework to modify its objects and recompile it just so my app can have this feature. I can hack around it and fake it with weak references and dictionaries and other shenanigans. Or I can just design it more flexibly in the first place.

Many of you will say but javascript is loosely typed. I'm saying so what. Those adhoc types
reconfigure themselves organically as you build your app. Most of us have no clue where a piece of code is going to go until we write it. JS accepts that as a virtue of its design. Pretend I'm really dumb and don't know how javascript inheritance actually works, but I know closures.

var id = 0;
function getNewId() {
return id++;
)
function Type1() {
this.Type1_ID = getNewId() //this object is of type Type1 (it's easy to tell)
}

function Type2() {
this.Type2_ID = getNewId() //this object is of type Type2 (it's easy to tell)
}

Oh wait, you think, I could put the ID in a shared "subclass".

function IDIfy(o) {
o.IDType_ID = getNewId(); //unambiguously subclassed with low effort and a bit of auto-renaming in your fave IDE
}

function Type1() {
IDIfy(this);
}

function Type2() {
IDIfy(this);
}

Try and do that as easily with C# and Java.

Just my 2 cents.

Anonymous said...

XAML is like dealing with a cursed monkey's paw. You ask it something simple and it delivers, but with an ironic twist. For example:

"I wish for scrollbars"
The scrollbars work perfectly. But they are invisible until the user hovers the pointer over them, making them worthless. The property you'd expect to change this behaviour does nothing and you're forced to basically rewrite the implementation to override the internal styles.

This is what dealing with XAML is like. Nothing "just works", there's always an issue to deal with. People who claim it can do no wrong either have a very limited scope they use it for at work or they haven't made any real applications outside of elaborate demos.

Unknown said...

I spent all day on WPF and I am utterly shocked and horrified at it. After learning about it for weeks:
1. I really like C# as a language
2. I get MVVM finally after a break through that the ViewModel is a model for the view, not a view for the model. Still not sure if I love it, but it's at least a decent pattern once people agree on what the ViewModel actually is.
3. XAML is a nice dense way to display the GUI. I like my GUI code not being hundreds of lines of adding one element to another.
4. Databinding gives cool capabilities to have code sections auto-update related sections.

So I like the four pieces of WPF, but when you put them all together, it's complete garbage. Today I spent about five hours *trying to bind the visibility of a column to a variable*. It would take five minutes in any other language. I had finally thought I got this whole databinding XAML incantation thing down, but it didn't work. No errors, no warnings, it just didn't work, the column was always invisible.

So after a couple hours of frustration, my coworker taught me how to get error information - you run a debugger. Yes, the only way I had to see errors containing valuable information is to run a debugger. And in my environment I can only remote debug due to not having a lot of pieces installed on my host. I'm used to dynamic typing in Python, but where Python takes away, it also gives in extremely simple syntax and an abundance of documentation.

So after I got the cryptic error info, I used it to search. I discovered that grid columns don't use datacontexts. My coworker thought I could hook it into the ancestor, but that failed. After searching more, turns out it is completely separate from the view datacontext. I found a few workarounds, none easy to implement. I tried a couple that didn't work. I finally found one that worked by adding in a "fake" invisible element that knows about the view datacontext but can somehow be referenced. However, that one stopped working when I put my boolean to visibility converter in. The last solution that finally worked was to create a "freezable class" as a proxy element that can be referenced but knows the DataContext because "Freezable objects can inherit the DataContext even when they’re not in the visual or logical tree". I still have no clue what a freezable class is and if I should be concerned about using one.

So at the end of the day, I spent several hours figuring out how to hide/show a column when a variable changes. The WPF databinding cool concept completely failed me in two ways. First, it's dynamic nature means that you have no intellisense, compiler, or even runtime errors and have to resort to a debugger to get basic error information. Second, the entire purpose of databinding was worthless because the thing I needed databindings to was, for some non-obvious reason, not referencable without looking up several blogs each with different complex solutions. I cannot believe anyone thinks WPF is a good idea after today, I keep thinking it has to be a joke!

Anonymous said...

To expand on Michael Lombardi's comments, March 23, 2018 at 12:01 AM:

"no intellisense, compiler, or even runtime errors and have to resort to a debugger to get basic error information."

So I have some theories on how intellisense works and have done some reading on the subject. Let's say it is a combination of reflection on your project assembly and dynamic code parsing. However, reflection would require that the source be compiled after making recent changes. I have seen issues that were resolved by a "rebuild" so I believe that reflection is used in some cases and dynamic code parsing in others. I could be way off base here.

It would seem that with WPF/XAML if you can't get intellisense to point you in the right direction (DataBinding etc) then the chances that your runtime will actually work are minimal: no runtime exception is thrown but possibly rooting around in the debugger might yield some clues. The WPF runtime seems rather silent in providing diagnostic information. I would cite this implementation defect as a source of much frustration on the part of many developers. Perhaps some way of snooping on the runtime reflection calls could help in not only understanding the issue at hand but deciphering general runtime behaviors at large.

My question is how though trial and error can a developer discover the insight to troubleshoot such problems? Some sort of design-time + runtime introspection tool could make the discovery process less clumsy.

Comments are appreciated.

Anonymous said...

FYI: https://www.infoq.com/news/2010/07/Data-Binding-Errors

The primary document on data binding in WPF is the simply titled article Data Binding Overview. While being a must-read for any WPF or Silverlight developer, it offers nearly nothing when it comes to debugging and troubleshooting. The entire section is literally just one sentence.

Debugging Mechanism

You can set the attached property PresentationTraceSources.TraceLevel on a binding-related object to receive information about the status of a specific binding.

Karl Shifflett offers some instruction on reading that data binding traces, but rest of his advice consists of obvious things to check like whether or not the DataContext contains the right object. And since Silverlight often runs outside of the IDE, even that isn’t always an option.

Fortunately there are a couple of third-party tools to makes things a bit easier. Cory Plotts’ Snoop can attach to any .NET 3.5 or 4.0 WPF application. Once loaded, it gives you detailed information on the control trees, where properties are getting their value from, and any data binding errors. Snoop 2.6 is available on CodePlex under the Microsoft Public License.

Another tool is Karl Shifflett’s Glimpse. This tool cannot be attached to a Silverlight application; it must be compiled into it. Once started, it will alert the user to unhandled application and data-binding exceptions via a floating window. Glimpse for Silverlight can be downloaded from Karl’s personal blog.

An often cited technique is to add a dummy value converter and then set a break point within it. Marlon Grech goes one step further by showing how to write a Debug Converter. By hard-coding a break statement in the code he eliminates the need to manually set a break point.

Morten said...

It is possible to get intellisense for the XAML editor in Visual Studio by specifying a DesignInstance for the DataContext. Of course, I had worked with WPF for quite a few years before I discovered this...

Anonymous said...

I think that they lost the main programming idea. Development should be easier from newer platroms. When i started to learn winform i had a result in my projects in first two days,with wpf i couldn't have a result. It's very complicated, and i dont want to spent time to another platform which looks more difficult than winforms to me. I agree that winforms need to be changed, but with a platorm which uses same code commands, so developers to not need to re learn a new programming commands all over again.

Ghdjd said...

It is now 2019 and most of the problems are still there. When you are developing simple things that work the first time it is easy to forget how crappy WPF really is.

The rendering is slow, data binding does not work well (as opposed to ie. Angular or other web frameworks)
Very simple XML tree traversals take huge amounts of code and are executed very inefficiently.
Interactions between user controls take huge amounts of code to make the DependencyProperties work and even then it often doesn't work if you do anything out of the ordinary.

Apparantly nobody builds Windows applications today anymore and if you want to make something that works you are stuck with web-technologies or Java?

Anonymous said...

I thought I'd seen it all after almost 40 years in IT. WPF/XAML sucks. Lots of things can't be easily done e.g. one line of code to set a property value. Can't set a simple color property on a control? Can't easily get a sane position. Can't set Z order.

David said...

It has a steep learning curve because it's undiscoverable.

Nailed in it one sentence! I really dislike (hate) the technology. I've never been less productive than when I have to use it.

Barba Blanca said...

It's been a year since I started with WPF. I had a very very hard time learning it (plus being a junior dev). Definitely not the best way to start in .NET
I've become kinda fluent, but still I have to google some weird xaml incantation from time to time.
I love C# tho.

Anonymous said...

Code + Winforms = Very Productive.

Code + XAML/WPF = Very Frustrating.

Anonymous said...

XAML is great. WPF is great. MVVM is great.
They are great tools that takes some time to understand.