TheWerewolf TheWerewolf

Niner since 2009


  • Hanselminut​es on 9 - Why Aren't There More WinForms Talks with Rocky Lhotka

    Forms behaves the way most non-web designers work and think. It's intuitive and natural.

    WPF is backwards and complicated - adding typically unneeded flexibility at the cost of significant complexity. If the dev studio team actually made the designers for it as simple and natural to use - I'd use it - but they're not.

    I was at the .Net Rocks session last week and the presenters were doing the classic "bear video in button" demo and I challenged them to do it *without typing ANY XAML* and they failed. I knew they would because it's essentially impossible to do that demo without cutting XAML. But it's not just that - simple things - like embedding graphics in controls - or even positioning controls are amazingly backwards in WPF relative to Forms.

    There's a lot of stuff in WPF I'd like to use - but there's so much weird baggage that in my opinion *wasn't necessary* that it's just not worth it to me.

    Want some immediate examples?

    When your new architecture *breaks the language paradigm* you might want to rethink what you're doing.

    1) C# (and most .Net languages) have the concept of a Property. It's a way to encapsulate a value making it look like a varable, but with code behind it. This explicity replaces the old SetXXX() GetXXX() accessor methods you typically see strewn through C++ code.

    Guess how the WPF system works? Yep. SetXXX() and GetXXX() all over the place.

    2) I understand the philosophical underpinnings for the notion of a page owning the position properties of a control it hosts - but - in most development situations, the way people think about controls is where it is and how big it is. By moving "where it is" to the host, you break the previous paradigms - but worse, you've implemented something that's *logically* sound but *practically* unsound. To make it worse, *getting* those properties is surreal. Why not use *attributes* - something that's been in .Net for a long time - to handle this?

    3) If you've used WPF for any length of time - you quickly realise that the entire design metaphor is for a *WEB PAGE*, not a desktop application. We've BEEN through this. The huge A-HA moment for the dev team was 1.1 to 2.0 when they realised that the golden age of everything running on a browser wasn't happening and that maybe desktop developers were important too.

    4) The fact that you made database connectivity an order of magnitude more difficult - and have only fixed it in VS2010 (kind of - it's easier - but still not as easy) shows me you don't understand what the bread and butter of desktop apps is: DATABASES. Everything is a database and almost all applications are about how to get data into them - and how to display then nicely. The fact that WPF's designers couldn't simply let you access database content visually is a HUGE clue that someone is out of touch.

    5) If you have to go into the code to do *anything* other than business logic - you've taken a step backwards. One of the main advantages of Forms is that I didn't have to do think about UI. I could slap down controls - hook most of it up in the property page, double click on the relevent stuff - maybe hook up a couple of events and bang - application.

    NOW I have to cut XAML, I have to know two languages (XAML and C# and constantly switch between them), I have to figure out relationships between them - and if I really want to do a good job - I have to get Blend in the picture.


    We've just gone back four years. The current crew doesn't understand that most application developers aren't web developers and don't WANT to be web developers. More importantly, the design goals and target audiences are entirely different and expect different behaviours in their apps. By trying to make desktop apps look like web apps - you're NOT helping us.

    WPF could be the greatest thing since sliced bread - but the FIRST thing that has to happen is to understand why Forms are so popular and then make the starting configuration of WPF look like it... then let the developer turn on stuff they want.

    The way it is right now - I'll use it when it is literally the last possible solution to my problem.

    It's just not worth the effort to get things working.


    Sorry - but I *LOVE* .Net. The people around me are sick of hearing about why I love it. And you're taking all the fun out of it for me. Yes, I'm ticked.

  • Update on some new site features coming in the near future

    Why not use Silverlight/ASP.Net for this?
  • WPF Design Surface Improvements in Visual Studio 2010

    I have to ask. I keep seeing these demos about WPF in Visual Studio and everytime, they claim 'things are easier'... and perhaps compared to earlier versions of WPF/XAML editors, they are - but so far, every example I've seen is an order of magnitude of complexity over Windows Forms - while rarely adding much value.

    In this video, there are several beautiful examples of this.

    When he adds a menu, it doesn't go where you'd expect. Then for some reason, he *manually* deletes the default settings - which is equivalent to opening the designer.cs file and editing the generated code, then fiddles with it to the point where it vanishes entirely. Then he has to find a way to actually select it (since it's zero height) and then he ends up in an entirely detached menu editor.

    In WinForms, you just... drag the menu to the window. You edit the text IN the window. You edit the parameters - which are explicitly shown in the parameter panel - which brings me to the search feature shown.. it assumes you know the parameters before finding them. That seems harder, not easier.

    The design of WPF really feels like someone's trying to develop a UI design language that looks like HTML - but HTML is one of the worst UI design languages out there. A lot of the 'new features' do not seem to actually make things easier - or when they do, it's fixing something that was made unnecessarily complicated by the design of WPF - and isn't that complicated in WinForms.

    Watching this video leaves me with one thought: I could so most of this in 1/10th the time in WinForms. I'm still entirely unconvinced that WPF is better - except for things that ONLY exist in WPF that the architects of this refused to back engineer into WinForms.

    Sorry if I sound negative, but I feel the .Net team is, once again, ignoring desktop application developers - or worse, trying to make us into web designers at gun point, which is amazingly frustrating. The feature that most appeals to me about .Net and WinForms is that I *don't* need to know the underlying UI code (even if it's now XAML rather than C#) and could focus on the business logic under it. It seems that this is going away.