Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Hanselminutes on 9 - Why Aren't There More WinForms Talks with Rocky Lhotka

Download

Right click “Save as…”

Scott's in Norway this week. The speakers in the speaker room are preoccupied with death and now they're asking about the death (or not) of WinForms. Rocky says he wants to see more practical talks on WinForms and advanced techniques but that most conferences aren't interested in those kinds of talks. Too much future tech too soon and too fast? Peter Provost jumps in as does Scott Bellware.

Tags:

Follow the Discussion

  • Tommy CarlierTommyCarlier Widen your gaze

    I'm still a heavy user of WinForms, both at work and at home. I'm very familiar with it, both with WinForms and even lower-level Win32 and GDI/GDI+, and I still think it has a performance and productivity advantage for most regular applications. The tools I use (and develop) don't need rich interactive media and animations and buttons with graphics and multiple lines in them. I have enough experience in WinForms and the lower-level API's to customize my controls if I need something a bit fancier.

  • As a member of the team that produces our MIX and PDC events (and someone who participates on our Tier 1 events council at Microsoft), I'd love to hear feedback on this topic. We're listening!

  • Vesuviusvesuvius Count Orlock

    This is a little like the C++ guys complaining that all the interviews are C#.

    I have in depth knowledge of Winforms, ASP.NET and am now earning my crust in WPF. I think that there are still huge gains to be made using Winforms over WPF in more than a bunch of areas, and Microsoft marketing have gotten a little too much influence over "selling".

    Microsoft have been muted in this regard, because they have not invested in the technology for years - although 3rd parties have - meaning that in product launches or conferences based around the innovation of the company, it is all too easy to forget. In some ways, they "threw the baby out with the bathwater" because they are like teenagers with music, always looking the next big thing!

     

  • Personally I was disappointed with TechEd this year (my first) *because* I expected there to be lots of talks about advanced WinForms and other related topics.  Visual Studio 2010 and .NET 4.0 are great, but the reality is our company is our department is just now getting the green-light to spend the time to transition to VS2008.  We develop a large WinForms app and our data shows that only ~50% of our customers even have .NET 3.0 installed; moving to WPF is the goal but WinForms is the fact right now.

    WinForms has lots of catch-22's, and what we do in WinForms that we consider to be advanced is probably more along the lines of medicre hackery to get by--true advanced WinForms topics are beyond what we want to learn on our own because there can be so much pain in learning about the limitations and boundaries before getting the understanding of the capabilities.

    I went to TechEd really hoping to get the nitty gritty details and pointers for VS2008/TFS2008, and really hoped to find some advanced sessions for topics applicable to .NET 2.0 such as databinding, memory management, intensive debugging (post-mortem type stuff with windbg, performance tuning, etc... instead it was largely a week of "here's what you could do if your customers used Vista (they don't), kept the latest version of .NET installed (a few do), use SharePoint (not in our business).

  • ...just finished watching the rest of the video...

    Productivitity is slippery.  To be able to make use of these productivity-enhancing technnolgies and features at the very least requires one to take a non-trivial amount of time to learn how to use them; time which is very close to 100% unproductive.  Once how to use them is known then one has take the time to ask "can I use them?", if the answer is no then it's 100% time lost--if the answer is yes then there is almost always a fair amount of unproductive time spent trying to find out how to leverage these productivity-enhancers in our unproductive environment--and usually even more time lost working to correct the mistakes that don't immediately rear their heads (fighting .NET quasi-memory leaks because RemoveHandler wasn't ever called?  Not calling EndInvoke() on delegates, etc...)

    Unfortunately we've had a number of run-ins with "productivity boons" which we can't fit into out current systems.  Like Scott's WCF example we run into buggered implementations which prevent us from smoothly using the newer systems--often times these basterds are the product of green developers trying to get their first system to work, or the product of salty devs who learned how to make something work and just don't care if it's been done correectly.  It's difficult to learn how to do things correctly--it's harder to learn the correct way to do things than it is to actually do them.

    To bring it all back around though...  having either a good mentor or a good resource can make a huge difference between stumbling around in the dark or heading in the right direction.  In my personal experience the best productivity gains don't come from new technolgies, but learning better implementations of the technoligies I'm already fluent in.

    +1 for having more advanced talks on existing/older technologies.  Now just to define the scope of "Advanced"

  • In the video, the comment about "be able to get stuff done, get paid and move on" sums it up for me.

    WPF just doesn't solve any problems my company or our customers have. I think that's why so many people want to stay with XP - it's not as slick but it does the job and there is no obvious benefit in upgrading.

    Where I've had a need for some custom component on my forms, I've managed to write something (if it's relatively easy) or buy an existing component. My preference is to always buy something over building from scratch or to reuse something someone else has written.

    If I was to write a new product from scratch, I would consider WPF but I suspect I'd stick with the tried-and-true WinForms.

  • 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.

    THIS IS NOT GOOD!

    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.

  • Disclaimer: My opinions and thoughts are my own and are not reflective of my employer.  My opinions are a result of being frustrated by the Framework or from Microsoft thinking that shinny is more important than support.

    Productivity #1
    Not everything is new and shiny!  Most of us work on brown field applications.  Green field applications are few and far between.  Brown field apps are mostly VB6 or Windows Forms, not WPF for me.  I learned MFC this year because I had too (yes that right, I learned MFC in 2009).  I would love to know how to make a Windows Forms app that looks like Firefox, Outlook, Word, or even Excel, but it’s difficult when tooling is inconsistent, and even when Microsoft internally can’t agree on a UI Framework.  I mean, you don’t even have the Office Ribbon in the Framework, hell, you gave MFC the ribbon before .NET, yet you preach .NET.

    Productivity #2
    The problem with WPF unlike Windows Forms is that the tools SUCK!  They are hard to use, expensive on system resources, and sluggish.  The Windows Forms designer is zippy and it's simple to get my stuff done.  I do want to have neat animations and transitions in my app, but I feel those should be provided by APIs like "ShowDialog()" not by me having to bake a transition in XAML.  Or even allow me to get them from some type of gallery.  In Windows Forms, I’ve never written code for the UI, I use the designer or I buy a third party control.  And if I want to do something cool in WPF I have to go buy Blend now?  I have spend more on a tool that just does UI design, I can’t get approval for that.  So that means that Visual Studio is just a glorified version of Notepad?  There are times when I load Notepad++ because I know the Studio won’t be usable for at least 45 seconds.  Cold start performance sucks.

    Productivity #3
    What you see in the designer is not what you get.  In the old days (by this I mean circa 1999), when you built a VB6 app, what the designer showed was what the app looked like, including window chrome.  You dragged a button out onto a form and where you dropped it was where it stuck.  And you could take that design and replicate it in a reasonable amount of time in Windows Forms.  In WPF if you want four buttons at the bottom of the screen like VCR controls, you need a stack panel first (orientated horizontal), and then you need to put those buttons in there.  That is a complete departure in how you think about Windows Apps.  We were trained that Windows Apps are grid-like and not web pages, and as such, they work differently.  Not to mention that in VB6 and Windows Forms, the designer looked exactly like the final result.  In WPF you get a white rectangle with a grey border that looks nothing like the final result when you press F5.  Also, I can't use Spy++ to inspect the elements in WPF.  When I do, I get "DirectUIHWND", what is that?  I wish that Spy++ worked like Firebugs in Firefox, now that would be useful.

    Productivity #4
    I want the speed of Visual Studio 6 with the tooling of today.  Today, it takes Visual Studio almost 45 seconds to be usable.  Think of it this way, would people use Excel if it took 45 seconds to be usable?  I can open a 45K or 45MB Workbook and the UI is still responsive in seconds.

    Productivity #5
    It seems that Microsoft is spending their time on things like LINQ instead of improving the tool.   And even that is inconsistent, because now we have the Entity Framework.  We ADO.NET, OLE DB, ODBC, LINQ, JET, and Entity Framework, to talk to databases.  There is no consistent way to get your data, so I use NHibernate, which is awesome compared to any of the above technologies.  I wish that more .NET stuff used configuration instead of attributes.  Also, there still is not LINQ provider for Access, which believe it or not is heavily used by many ISV in Oil & Gas.

    Productivity #6
    I really look to Microsoft to see what you can do with WPF and the new graphics library; I mean you wrote it for heaven’s sake!  How many people do you know didn't buy an Apple because the UI is sexy.  The transitions are sweet, the effects are well thought out (windows flip is a prime example) and the OS is generally nice to look at.  My Mac runs Windows (but if I want to cut video, like I did for Ping, I use iMovie).  If Microsoft wants developers to use WPF and get excited about it, then show us what you can do with it.  You guys built the technology; you should know how to make a textbox "light up" as you put it.

    Productivity #7
    Slow adoption of Windows Features to Framework Support.  I've ranted about this in the past, why is the Framework behind Windows features?  If Microsoft wants everyone to buy Vista or soon 7, then make those shinny Windows features accessible from .NET without requiring a PhD.  It's almost a three full years after Vista’s launch and we still don't have Command Links,  Dialogs, or Aero Wizards baked into the framework, we have to use Vista Bridge.  It just baffles my mind!  I hear radio shows talk about this (including .NET Rocks) and I have my clients ask the same questions, why can’t your app look like that.

    Productivity #8
    Why is Office Development so difficult?  I know almost no one who takes Excel, slaps a button on the UI and write .NET code inside it.  I know lots of developers who automate Excel to read in hundreds or even thousands of Workbooks, transfer that data to another application, maybe update some data, and then save that back to the Workbook and close it, without ever showing Excel. 
    It is so fragile.  Why isn’t there a complete wrapper to talk to Excel or Word yet?  I’m so frustrated by VSTO I’m evaluating third party libraries to help me out.  The Excel 97-2003 file format isn’t XML like the new file format, and most of my clients are three or four versions back because the new Office doesn’t do anything the old one can’t.  COM is hard, the only people I know who use it or understand it are Microsoft, but yet we still have these fragile wrappers which take a PhD to understand.  I’d rather pay a third party a grend for a .NET wrapper (which is more than Office costs) because I can do things which seem backwards from .NET, or are just SLOW. 
    It amazes me, we have Azure (which is Microsoft tying to be everything to everyone again) but we still don’t have a stable solution to read data from a Workbook.

    Thanks for listening.  I will now go back to my desk Smiley

  • I tend to agree with Scott Belware's definition of productivity in the context of software development.

    Getting the fewest number of keystrokes is a very narrow view of the problem. Of course it's hugely important to have expressive languages and good tools to quickly output code but it's only a small part of the overall picture of software development: the main aim of it all is not to reduced to allowing me to output more but to ensure that the entire ecosystem allows me to output a solution to a client's problem in the shortest possible time.

    I'd like Microsoft focus a bit more on how all these great technologies they've been churning out in the past couple of years are actually working together to help build applications faster.

    There is a lot of focus on introductory presentation on what they can do but very little in the way of showing us best practices and recipes around how they should be used efficiently.

    The truth is that, while WPF, Silverlight, MVC, WCF, and al potentially hold great promise, they are not making us more productive for a few simple reasons:

    Technologically Incomplete.

    They are fairly new, so they do not always cater for all their promised used cases. You cannot be sure that the productivity that was promised using a particular technology will not be negated by specific issues that have not yet been ironed-out. You'll end-up spending a huge amount of time going around these bumps.

    Lack of Proficiency.

    We don't know them. Any new language, development paradigm and technology (even tool) will take hundreds, sometimes thousands, of hours to master well enough that you don't have to spend 50% of your time Googgling (or Bingging) for help.
    By the time you're somewhat proficient enough to produce code quickly and avoid pitfalls, some other new shiny technology will have taken over. Corba is dead, vive Remoting! Remoting is dead, vive WCF!

    Negligence of older technology.

    As developers we like shiny new toys. I'd rather spend my time experimenting with C#4.0 than type another line of VBA. Yet, most existing software is based on these older technologies, and most developers spend their time supporting and developing new solutions using them.
    Windows Forms are not dead. Maybe we wish they were, they're messy, unsexy and built upon layers of old technologies, yet they're still there, making up probably more than 90% of the desktop apps out there.
    Strange thing is that, as noted in the video, they are conspicuously absent from the big events.

    Isolated Islands

    There isn't enough information about combining technologies together to build real-world apps.
    Examples, code samples, presentations usually focus on showing the first 10% of solving a problem with a particular technology.This is useful but when we reach the point of having to plug these technologies together, there isn't much help.

    Keeping up with it all

    We're only human and there is only so much information we can consume every day while still performing our primary job.
    I try hard to keep up with technologies because they sometime give you the edge, or render something that used to be complicated easy.
    Unfortunately, this comes at a price: I spend a good deal of my day reading on stuff I probably won't use; there's too much of it, too many new technologies, too many ways to do things, how do you make the right choice?
    It's somewhat paradoxical: you need to spend time trying to learn about new things that may make you more productive and in the process you are not doing any work.

    Helping me choose

    I would really like to see some kind of 'Microsoft Academy'. By this I don't mean a 'Police Academy' type of affair but rather a training video channel where, over the course of a number of videos, we would be shown how to use the technologies to produce real-world apps.
    Sessions during technical event are too short to go beyond the very basics. Even Scott's presentation on building NerdDinner had lots of ready-baked cheats that hide most of the real-world process of getting through a technology choice.
    My productivity is greatly affected by the right or wrong technologies I chose.

    Anyway, this short video has provoked a lot of long responses.
    That must be the Hanselman Effect!

  • ChevalN2Cheval Why not null?

    I would like to add my bit on the productivity comments in the video. From the comments above Scott makes a terrific point about the new tools being great until you find out that there is a show stopper in that they were not designed to do some aspect. I’ve seen that with WPF which is why we haven’t touched it in any serious way. The second point he made about productivity being the amount of work done with the fewest key strokes is totally off base. WPF again is the perfect example for this. It is so different and unfamiliar to WinForms that the less key strokes makes it much worse in productivity as your trying to guess where you need to type next? XAML, C#/VB code, maybe throw some XML or HTML and see if that helps. The boss wants to know why we need to buy Blend to make the invoicing part look good?

     Without getting off topic too much this also shows up in the treatment of certification. The most bizarre example is having being reduced to “hey, just print your certificate on your dot matrix printer. Employers will love that as it’ll save us a tonne of money! (cough, green environment something…)” So you have MCPD? That’s nice. There are so many parts and framework versions in that certification that you will be of no use to us as we need someone more generic/broad range skills. Can you actually just program WinForms?

     But really, if Microsoft wants us to use and take up these new technologies, then it needs to have code generators. Don’t reduce the number of key strokes, make tools that create the code templates which can be modified. An example of this is the Team Test system. Let it record what you want it to do and then have it spit out the code to make it happen. For the comment above about Excel, I actually find the VBA code spitter quite useful. It’s like the mini-intellisense for VBA. Without intellisense in Visual Studio, I’d spend 2/3 of my day crawling the framework doco looking for libraries that I could possibly use, then find out I can’t and then go and buy a third party component. That's an extreme point, but still mostly true due to another subscription upgrade just paid for.

     For that part in the video about old days, don’t forget how many applications got built in DOS Basic with it’s very limit command set… I can tell you some were not simple indeed, but quick in getting them done. Productive? There were fewer key stokes there as well. So by Scott's definition, yes.

  • WPF has a steep learning curve, for sure, but I think it's wrong to dismiss it as being a 'web style' tool just because XAML looks vaguely HTML like. And yes it's a little encumbered by the fact the VS designer is a bit limited (though pretty close to parity with the WinForms designer I'd say). However once you've taken the time to learn it, WPF walks all over WinForms in terms of being able to create UI for an application and going back to writing for WinForms feels horribly cumbersome.

  • Eh, so does anyone really think these developer conferences are about what technologies people really use, or what is the most suitable technology or tool to solve [problem x]?

    It is all about marketing the "next thing", and in many cases technologies that will never take off. Not about what people really use. That's why it is all WPF, Entity Framework, and WCF since a while back. And that's why Winforms, Linq-to-SQL, classic ADO, classic web services and other stuff that has a much larger user base is never mentioned anymore on conferences. Just browse through the PDC2008 agenda - shining example that the session topics are picked by marketing people and not technologists.

  • Wow, just wanted to point out that while WPF requires a different approach than WinForms, the pros far outweigh the cons. Two big ones for me are the binding engine and the disconnect between look and function in controls.

    Also, everything you can do in XAML, you can do in C#/VB. I'm really surprised the presenters couldn't do the "video in a button" demo without XAML.

  • BassBass I need better writers.

    My primary reason for not looking into WPF is it's too Microsoft-proprietary. If I use WinForms, I can write an application that runs on Windows, Linux and Mac OS X. If I use WPF, I only have the option of supporting Windows. That is quite unappealing. I don't want my business model to literarly depend on another competitor's or potential competitor's business model.

  • The majority of folks don't care about cross platform.  Those that do, are still taking a risk with WinForms.  Mono is great, but WinForms is a second class citizen (at best) on that platform.  As such, what you'd care about is not what the majority of others would care about, when it came to a talk about WinForms.

    I hear a lot of whining on here, but most of it is technically wrong, not relevant, or totally misses the point.  You should no more expect to hear about last years tech at these conferences as you'd expect to hear about last years Prius at a car show.  If you want a session about WinForms, there are numerous instructors out there that you could hire.  You'll be better served by that than you would be by the typical conference presentation any way.

  • BassBass I need better writers.

    Maybe, but I am stating my reason for not liking WPF, which I think it interesting because it's not "tooling sucks" or whatever the last 5 posters were talking about. Maybe it's not a "popular" reason, but it might be 5 years from now, because Windows marketshare is declining. IMO it's not a good idea to write software that can only run on Windows today. Software that is not tied to a platform gives your existing customer's choice, and expands your customer base at the same time.

    And regarding Mono WinForms. It's better to be a second class citizen then not a citizen at all. Smiley Mono developers spend more time perfecting WinForms then GTK# anyway. Smiley With WinForms I can have a nice looking app on Windows, and a decent app on OS X and Linux. I was mostly targeting Linux I'd use GTK#, but Windows is still the primary platform of business, so WinForms is a better choice.

  • I think the point is you can't do the "video in a button" demo purely with the VS2008 visual designer, you have to use either code or, more likely, XAML. Quite how that is relevant to creating LOB apps is beyond me though. And ultimately, while it might require a smidgen of XAML knowledge (or Blend)  to put video on a button in WPF, try doing the same thign in WinForms, even with a huge amount of code.

  • That makes more sense then. The designer in VS2008 is a little lacking, although there's so much you can do in the XAML, I just don't think it can be translated over to the designer in a more productive way. I'll have to mess around with VS2010 a bit more to see what MS is doing in that area.

  • You may be right about the car show, but when we have a new car show we aren't told that Honda has invented a new way to drive, that we all must adopt because marketing wants to recoup all the research and development costs.  We are also not told the car no longer drives on roads and we need to relearn how to drive, operate the controls, and have to buy a new garage to store it.  Driving hasn't changed much since it was invented, luxury options and environment consciousness has only improved.

    The fortunate part for Microsoft is that software isn’t tangible (as a car is) so they can change the rules with each new release.  And if everyone loved the releases we’d all be using new and shiny, the plain fact is we are not.

    You call it whining I call it realism.  Most of us don't have six months where we can take a hit on revenue.  You might but I don't

  • I would say using the right tool for the right job is the best solution.  WinForms is still the best tool to use for creating applications that fit in with the look and feel of Windows.  It's also much better suited to business type applications with great RAD support for drag and drop data binding.  WPF on the other hand is better suited to applications where the user interface IS the application and requires a UI outside the scope of standard Windows controls e.g. a family tree application where relationships are displayed in a visual manner would obviously be best implemented in WPF.

    When creating new applications, WinForms is still my preferred choice in most cases.  If a situation does arise where a part of the application really needs some non-standard UI which is beyond the scope of the WinForms controls, then I would simply drag and drop an ElementHost onto the form and link into some XAML.  However, for the majority of business applications we write at the company I work for, there's no need for this at all - about 99% of the controls we need are already present in the framework or through third party controls.

    With WPF comes great power, but also great responsibility.  I've seen some absolutely hideous WPF applications out there.  At least with WinForms, you're pretty much guaranteed an interface that is fairly familiar to end users.  Sure, WPF can have videos on buttons, but what has that achieved you?  Puzzled users usually!  Plus, as the Windows themes evolve over the years, will your polka dot splattered WPF application still look modern?

    Don't get me wrong, the declarative WPF approach is definitely the correct direction to aim in.  It's just that WPF has so many negative points, that's it's just not worth moving to until all the productivity draining issues have been sorted out.  It does seem to be improving, but it's at an excruciatingly slow pace.  For example it's pretty hard to believe that it was only November last year that WPF finally got support for double clicking elements in the designer in order to automatically hook up events!  It's just not worth investing in WPF until Microsoft get their arse in gear and get the major WPF issues sorted out.

    Other reasons for not using WPF include:

    • Poor WPF design time experience - too much focus on XAML and not enough on the designer.  My goal isn't to write XAML, it's to create an interface, and anything else is a productivity draining distraction.
    • In order to create even a half decent UI you're going to need to hire a professional designer.  Not every company has the resources for this.  This also involves the additional purchase of Blend.
    • There is still no built in data grid (unbelievable!).  Yes I know one is in development on CodePlex, but that doesn't count as it isn't even finished, and it needs to be something built into the product to be viable.
    • Too much plumbing work e.g. manually hooking up bindings in XAML using bizarre syntaxes.  It's not fixed yet, but it's great this is partially being addressed in .NET 4.   Then there's all the nonsense with dealing with resources at just about every step.  We shouldn't have to worry about all this plumbing work - it's like going back to the dark ages.
    • The built in dialogs don't even support windows themes.  Try doing a MessageBox.Show and look at the Windows 95 button!
    • Property grids in the designer are simplistic and unhelpful (i.e. just a text field to pick a color!!!).  Again, thank goodness we're getting a color picker in .NET 4.  Is it really progress to be excited about getting something we've had for years in WinForms?
    • Total lack help in the designers - e.g. no help tips in the XAML window and no help text at the bottom of the properties window.
    • Non-standard look and feel.  By default a WPF app does not conform to the Windows color scheme.  In fact it looks more like a Windows 3.1 application with its default white background.  We learned the "consistent look and feel" rule DECADES ago.  For the most part developers DO NOT want to reinvent the wheel UI wise for every app they write.  We want consistency with the Windows theme, or at a stretch, parity with the latest Office look and feel.  But users want it globally, not a hundred different UI's and controls for each different app.
    • Performance issues, especially on slower machines e.g. start up speed.  Is everyone happy with the performance issues with Visual Studio 2010 now that it's WPF based?  Hell NO!
    • Absolutely pathetic text rendering quality.  This has been bugged on Connect and sat there ignored for YEARS.  At least this is finally on the cards to be looked at in .NET 4 beta 2.

    At least there is a glimmer of hope of some improvements in .NET 4, especially now that MSFT are dog fooding WPF in Visual Studio 2010 and they're finally getting a taste of the pain points of developing a real world application in WPF.  According to Microsoft themselves, WPF issues have set the VS2010 schedule back by months.

    For now, I think I'll stick with WinForms thanks.  In the meantime, I'll certainly be keeping an eye on the progress of WPF.  Hopefully one day it will actually be a feasible and productive technology to use in the real world.

    -Dan

  • Re: Car show metaphor. A car show is a consumer event. We are not consumers. Think of PDC and TechEd a our equivalent to a Surgeon's convention. When there is a new procedure, it takes learning and training in order to become with the new procedure. What we do is more akin to surgery than driving a car.

    BTW when the horseless carriage (aka car) was first introduced, you best believe that it required new kinds of roads and new "stables" and learning a new way to drive their carriage.

    WRT this entire thread...if you expect your application to just work after dragging and dropping a bunch of widgets on a form, what are you adding to the procedure to justify your salary? Yet you have the nerve to complain that your job is being given away to offshore developers and H1-B. Guess what? If you do something that makes your contribution more valuable that a $15 dollar an hour developer, you just might make yourselve a little less expendable.

    If you don't care enough about your career to invest the time, effort, and *GASP* money to advance your career on your own, why should your employer and/or clients care?

  • ChevalN2Cheval Why not null?

    Brownie: I understand that the above comments appear to only be whinging about having to roll up the sleves and do some work but... (there's always a but) you're missing the point entirely. Actually you're missing two points.

    The first is that in regards to WPF and Winforms, it's just the GUI. Why does one need to take three times longer to display an invoice in WFP compared to Winforms? I'm not just talking about the time to press key strokes and work around the IDE, but the time for the IDE load times and application runtine as well. There seems to be the old saying with every new technology the core is worked out (eg. MSBuild over Visual Studio compiling, some apps won't even compile in VS) "What Intel givith, Microsoft takes away".

    The second is about productivity, my time as a developer should be spent on bringing the business solution to the computer. Not fussing over the tools. That's where my value is over offshore developers. It's all about getting the system they want to make money for them as quickly as possible. It doesn't matter what language or tool, C++, C# or even assembly, just matters that what they need to get their job done as efficient as possible. As developers we are *only* the enablers of that, not like the medical overlords that the business and everyday folk must come begging to.

    Notes: I also agree that declarative nature, the self organising layout and the bindings functionality in WFP is a fantastic idea, just not "productive" IDE experience at the moment. I also think declarative programing is also the future with going back to the true maths and linear data types, but that's another discussion. Shared state and variables, so 1970's...

  • I agree with the other posters.  Microsoft has basically lost its way.  Things are not getting easier as they should be but orders of magnitude harder.  At this rate Microsoft will find itself in the dust bin of history.  I almost get the impression the people developing the products have never actually developed a real world application. 

  • If you dont' like WPF, don't use.  Don't expect a convention to cater to older tech though.  It's unrealistic, and ain't gonna happen.  Heck, even WPF is already taking a bit of a back seat.  Not much new in WPF for the last convention, so the vast majority of the sessions were on Silverlight or some other tech instead.  WELCOME TO REALITY.

    "Poor WPF design time experience - too much focus on XAML and not enough on the designer.  My goal isn't to write XAML, it's to create an interface, and anything else is a productivity draining distraction."  Really?  Are you a designer?  I don't know one designer that would agree with this statement.  WinForms provides a designer with NOTHING.  WPF, on the other hand, gives the designer a LOT of room to work, and Blend is the first UI design tool for desktop applications for any technology, AFAIK.  Designers LOVE WPF.  See, you make statements like this one, and you just show ignorance.  If you're ignorant, and yet take the time to write such a long post complaining about WPF, it can be nothing but whining.

    "In order to create even a half decent UI you're going to need to hire a professional designer.  Not every company has the resources for this.  This also involves the additional purchase of Blend."  Hmm... so now you contradict your first statement, and yet it's still a phallacy.  I'm not a designer.  I don't use Blend (I mean to start, just haven't gotten around to it yet), and for that matter I don't use the VS designer for anything more than a preview.  Yet I create forms that generally far outsurpass the quality of what I used to do with WinForms, and I do so with more productivity (keep in mind that I'm proficient with WPF... I'm not claiming *you* will have the same productivity any time soon).

    "There is still no built in data grid (unbelievable!).  Yes I know one is in development on CodePlex, but that doesn't count as it isn't even finished, and it needs to be something built into the product to be viable."  Yet, I've done many a design that's included a Grid.  Oh, how ever did I manage it?  The truth is, around 80% of the designs you're going to do with a Grid can be done with a templated/styled ListView with little effort.  The other 20% could still be done with that ListView, but I fully admit it wouldn't be easy.  Yes, Microsoft dropped the ball here, but mostly from a marketing point of view. The reality is that the missing Grid isn't that big of a deal.

    "Too much plumbing work e.g. manually hooking up bindings in XAML using bizarre syntaxes.  It's not fixed yet, but it's great this is partially being addressed in .NET 4.   Then there's all the nonsense with dealing with resources at just about every step.  We shouldn't have to worry about all this plumbing work - it's like going back to the dark ages."  Whine, whine, whine.  If you can't figure out how to do Binding, you're lazy or stupid.  Really, the Binding syntax was NOT part of the steep learning curve that I freely admist does exist.  And once you know it, using it isn't difficult.  More importantly, you DO NOT have to learn the syntax at all.  Blend does a really great job of data binding visually, and the next VS designer will as well.  As for resources... what utter hogwash.  You dealt with many the same thing in WinForms (ObjectDataProvider anyone?), and for things that you didn't do in WinForms, it was because you couldn't, and you CHOOSE to do it in WPF (styling and templating).  And there's nothing difficult about it.  It's certainly not moving "to the dark ages".  Really, do you want some cheese with that whine?

    "The built in dialogs don't even support windows themes.  Try doing a MessageBox.Show and look at the Windows 95 button!"  How long have you been doing WinForms? That EXACT SAME complaint was leveled at WinForms to begin with, yet many people used WinForms any way.  I'm not saying this isn't a deficiency of WPF.  It's new tech.  There ARE deficiencies.  But none of them are anywhere near as onerous as the whiners in this thread are making them out to be.  More important, it's still not relevant to the topic of why WinForms should be given any attention in a conference.  There are valid reasons to choose WinForms over WPF, just as there are valid reasons to choose WPF over WinForms.  Anyone who's going to claim one universely superior to the other is selling you a crock of beans.  But even if there were more legitimate reasons to use WinForms than WPF (which isn't true), you still shouldn't expect to see WinForms in a conference.

    "Property grids in the designer are simplistic and unhelpful (i.e. just a text field to pick a color!!!).  Again, thank goodness we're getting a color picker in .NET 4.  Is it really progress to be excited about getting something we've had for years in WinForms?"  For better or for worse, if you want to use a designer, you should be using Blend.  Even after the next release, when the VS designer will catch up with and possibly surpasse (depending on POV and usage) the WinForms designer, you're still going to be better off using Blend.  I can understand complaining not liking that, and even the complaint about something else one has to buy (not true if you're developers have MSDN subscriptions).  But this still comes down as skewed opinion with no relevance to the topic.

    "Non-standard look and feel.  By default a WPF app does not conform to the Windows color scheme.  In fact it looks more like a Windows 3.1 application with its default white background.  We learned the "consistent look and feel" rule DECADES ago.  For the most part developers DO NOT want to reinvent the wheel UI wise for every app they write.  We want consistency with the Windows theme, or at a stretch, parity with the latest Office look and feel.  But users want it globally, not a hundred different UI's and controls for each different app."  Total FUD.  WPF does respect the Windows theme.  Not 100% faithfully, no, but then, neither does WinForms.  Both can be easily picked out from other Windows by anyone with an attention to detail.  Again, this is THE EXACT SAME COMPLAINT that was initially leveled at WinForms, and despite that enough people used it that we've come full circle with these complaints about WPF.  So, more whining, and still off topic.

    "Performance issues, especially on slower machines e.g. start up speed.  Is everyone happy with the performance issues with Visual Studio 2010 now that it's WPF based?  Hell NO!"  Wow, do I feel like I'm in a time warp.  Again, the same complaint was leveled at WinForms.  And again, though some truth exists,the whiners still manage to drastically distort reality.  The reality is, VS2010 hasn't really gotten any slower than VS2008, at least for me.  The reasons why the performance of VS2010 is what it is (slower or not) are too complicated to point at any one thing.  There is a large start-up hit that was added because of WPF (if you want to spin things... the reality is that the hit is from the .NET runtime in general, and not WPF specifically... i.e. if they'd switched to using WinForms they would have had the same hit).  However, that start-up hit was offset by other improvements such that the net result is a wash (read the performance blog for details).  Individuals are going to perceive this differently, based on too many factors to list, including hardware, other software installed, etc.  So if you think VS2010 is slower, it probably is for you.  But the reality is that for most people, it's not.

    "Absolutely pathetic text rendering quality.  This has been bugged on Connect and sat there ignored for YEARS.  At least this is finally on the cards to be looked at in .NET 4 beta 2."  A legitimate criticism (though the text rendering even today is good enough for most people and most applications), but again not relevant to the topic.

    If you don't want to use WPF, don't.  If you want to criticise it, do so, but you'd better have your facts straight.  But the reality is that conferences are always going to focus on what's new, and WinForms are not new.  As for productivity, that's something that can't be measured as a universal.  In the old days this was something often leveled at C++ as a reason to switch to VB.  There was some truth in the claims that VB was more productive (for some class of applications, until you hit that wall of something VB couldn't do, or at least couldn't do easily).  However, I was proficient enough with MFC, that I coded circles around most VB developers.  I was more than productive enough, making the claims meaningless to me.  We're sort of in the same place now.  Trust me, WPF is more productive in the general case.  You just have to be know how to use it, and I'm not going to tell you there's not a very steep learning curve, especially for someone used to coding the WinForms way.  So, while generally WPF is more productive, it isn't universally.  If you're more productive in WinForms, then *you* are more productive in WinForms.

    As for me, I'm goint to "stick with WPF."  Today it is actually "a feasible and productive technology" that I already "use in the real world".  And I will never put up with FUD about any technology presented by anyone.  Stick to facts or opinions, but avoid opinions stated as facts, please.

  • It would be nice if Microsoft would spend a bit more time on marketing it's current technology instead of spending too much effort on the new technology.

    The rate of change with all the new technologies has kind of made me lose interesting in learning anything or buying books.  After about a year or so, the technology is old.  Sure, it all builds on the previous, but that's not the point. 

    Where does it end?

    I'd like to get the WinForm and Webform stuff working perfect and completely understand it before having to learn MVC, WPF, WCF, or something like that.

     

  • I give up. Take from someone that's been doing this a while.  The pace of technology isn't going to slow down.  In fact, it's going to increase.  If you're not ready for that, consider moving on to another profession.

  • For vector graphics development, I find the WPF API clumsy. I am not happy with the memory use either. I am not comparing to windows forms, but to other vector graphics APIs.

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.