WPF--Why? No, Really!
-
Like most of you, I spend my days (and many nights) in the trenches, and have for nearly 30 years. I came up through assembly to C through C++ to C#, and a bunch of other stuff as side trips along the way. Having come from a place where there were NO IDE's to ease my pain, I'm supremely grateful for the ability to drag controls onto a form, smoosh 'em around, set some properties and be up and running with a skeleton to flesh out and deliver. I do NOT work with or have access to a graphic artist, nor do I wish to. Anyway, for the last several months on and off, I have attempted to come to grips with WPF, and I've finally arrived at the conclusion that it's just not worth the effort! In general, it's more work and more frustration for MUCH less functionality! Come on, MS! If I want to tinker endlessly with markup, I'll write in HTML, and likely have something that works in much less time and effort. To obtain the same level of useability I get with Windows Forms apps using WPF takes unbelieveable amounts of time and effort. Latest and greatest, my achin' posterior! Am I wrong? What am I missing here, folks?? Too busy for the MS merry-go-round, Duane Doutel
<joking/ribbing on> Wow, you're old ! "When I was young all we had to play with was a stick and a rock and we were damn happy to have it" <joking/ribbing off> I both agree and disagree. I think WPF is worth it, I also think that it's been make incredibly/unnecessarily difficult. I remember reading Petzold complain early on that MS was removing features that made it easier for programmers to hand code XAML. MS’s justification was that no-one would ever hand-code XAML. Having worked with both Blend and VS, I can’t see how anyone would produce any sort of interesting large project without hand-coding. The problem with XAML is it’s a bunch of different mini-languages and concepts wrapped in some XML. Building up intuition about how one part works doesn’t help (and sometimes hurts) you understand other parts. XAML is very powerful, fearfully verbose and a bit bizarre, which is a combination that doesn’t generally lead to something friendly. That said, if all you need is winforms functionality, it’s probably a better “win-forms” than winforms, just don’t use the designers, type the XML in directly and don’t attempt to do anything even remotely fancy. To me it feels like XAML and .NET (framework) were created by two different companies that each accidently created something that could be mad to work with the other.
-
I've been spolied by WPF, and now I miss it when I have to code in MFC, Winforms, Win32 or QT. First thing - the code generated by the WPF Designer isn't great, I code all my visual trees by hand, and use templates for visual styling. Databinding is what makes it all worth while, you can even use databinding to control the viewstate, check out this excellent article by Josh Smith Simplifying the WPF TreeView by Using the ViewModel Pattern[^] Once you understand that article it opens windows in your mind. Other than databinding there's easy animations to make nice dynamic interfaces with collapsable panels and stuff, scaling and rotations to allow you to visualize data in new ways, the ability to restyle any control is nice. It does take a month or 2 before it clicks though, and some of the framework could be made a bit simpler, I think Silverlight is heading more down the right path and will probably end up as what WPF should have been.
John Stewien wrote:
check out this excellent article by Josh Smith
Personally knowing nothing about WPF., I noticed (under "The Big Bummer" heading at the bottom) of an article linked to by your article the remark "Unfortunately there is no supported way to programmatically set the selected item in a TreeView.". This is my generic fear, that like any wrapper-technology there may be fairly obvious things you might want to do, but you can't drill-down thru the wrapper to "get at them". How accurate is this "generic fear"; even in the cited example, is that actually true, it seems difficult to believe you cant set-the-sel-item.
pg--az
-
ddoutel wrote:
To obtain the same level of useability I get with Windows Forms apps
WPF ain't WinForms. Trying to use WPF as one would use WinForms will result in tears. I like my old, trusty WinForms. But I must admit to lusting after WPF's data binding and UI extensibilities.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
I have to say I'm a fan of WPF, and I write LOB apps, not fancy graphics stuff. Mostly I like the true heirarchical model where each control has a Content property that can contain any other controls, as well as the binding model especially when combined with Data templates. Styles are nice too, although I don't have the design skills to build anything truly beautiful (but steal a couple of nice Themes off the web, and you have instant sex appeal). I will say that the tools provided in VS2008 could use alot of work (some of apparently has happened in 2010, anxiously awaiting that release). The designer often fails to show the graphic representation, spits out errors that actually aren't (i.e. code compiles and runs fine, designer just chokes), and occasionally kills the entire VS session (helps to avoid 3rd party plugins, sadly). So I do most of the work in XAML, not drag and drop, which is OK with me, but I could do without the crashes, and it would be nice to see the results of my changes without running the app. Unfortunately I think the weaker toolset is turning people off of a really nice technology, especially when coming from WinForms which is a different model and so requires a learning/thinking curve anyway. Combine that with more mature tools, and I'm not surprised people get turned off of WPF. My biggest worry is that when we start hiring new developers we won't be able to find any who have WPF experience...
-
Shog9 wrote:
Then what the hell is The Soapbox for? Dirty jokes?
No,abuse of a more specific and personal nature, such that your fifth-grade niece shouldn't be reading it...if I understand the rules correctly.
-
Yup; both are very cool (databinding and customization). It's just that there's no sensible bridge to WPF from WinForms, no way to ease the transition. Most frustrating of all, I'm already bald, so I can't even tear my hair out, as any self-respecting bit-banger would do...!
That is a shame....you'd think hair regrowth products would have been improved enough to this point so that all programmers could tear their hair out at any stage of their career :laugh:
-
ddoutel wrote:
What am I missing here
The general consensus is that WPF is NOT WinForms. Frankly I hate WinForms and I've done a hell of a lot with it. However, I've also been doing excessively strange things with XML since 1997 and XSLT since 1999. I took one look at WPF and realised that if someone didn't come from a background similar to mine that they "wouldn't get it", especially not the actual XAML markup bit of it. I've already done some serious playing around with it when it first surfaced (using VS2005 - not easy), and once I got past the initial hurdles found it left WF for dead. But the problem that existed for me then, still exists today - that is, no decent tools to really give the thing a good flogging. The tools have definitely improved, but they're still not "there" yet. And it seems that's everyone elses complaint too. What you "could" do with WPF, especially in terms of automatically generated layout that doesn't suck, is a hell of a lot more than you could ever achieve with WF. But I don't yet see anything in the tools that are available that brings those compelling arguments forward. I think it's another classic example of MS doesn't get it right until v3.0. Gutenberg wasn't the first to invent the printing press. However, he was the first to bring together everything needed to actually do printing as a complete process. WPF is 'missing' all those other parts that make it into a complete process.
I just love Koalas - they go great with Bacon.
I agree about the tools; between VS 2008 and Blend 2.1, and not having a large amount of time to spend in a chunk to grok it all, it's just not gel-ing for me. Add to that that in spite of having invested in several books, being an MSDN Premium subscriber, and reading a bunch of the stuff at CodeProject, the markup is neither A)introduced well at all, nor B) covered comprehensively in a single place. To top it off, it would seem that one of the supposed strengths of WPF is in the graphics department, and the extent of my graphics experience is in writing Windows printer device drivers many years ago (dithers, diffusions, etc.); in short, I'm no graphics designer. Best regards, Duane Doutel
modified on Wednesday, May 13, 2009 5:34 PM
-
I'm not affiliated with the following site, but I've always found it a pretty good resource for learning things .Net related. I wholeheartedly recommend a lifetime membership. www.learnvisualstudio.net They currently have a series on WPF. It's 5 videos so far. It uses Blend and VS 2008 so if you can't get ahold of both of those you are wasting your time. You could probably get away with the C# Express Edition 2008 of VS, but there is nothing like that for Blend. It kind of annoyed me they used both of those tools, but it's good to see how they are meant to be used. Here's a direct link to the series page: http://www.learnvisualstudio.net/content/series/Windows_Presentation_Foundation_301.aspx[^]
-
Oh my G-d..... And I thougth that I was alone in feeling the way I feel about WPF. I also have close to 30 years in the trenches. After reading all the marketing materials about WPF I decided that this would be the next "it". I started playing around with it and in concept it's not a bad idea at all. Or is it? Why push all the properties of a control to XAML when you can keep them in the properties window? Why am I being forced now to remember all the properties and settings for control when beforehand all I had to do was scroll up and down that properties window? At least give me some decent intellisense... I believe in simplicity. If I cannot bind data to a grid and lay it out the way I need it at design time, then I'm not interested. Maybe it's because the WPF controls are not mature yet. Besides, what is really the advantage of all XAML? I was reading an MS article thattells you what to do when your XAML gets so big that it chokes the visual designer. Their soulution? Easy. Hide the visual designer and work only in XAML? So what happened to the "visual" in Visual Studio?
I hear ya! The .XAML is really nothing more in appearance than a DOM-like thing, and even in a moderately complex one, it's easy to get lost. I've never gotten to the point where the designer croaked, but I can just imagine the frustration... Best Regards, Duane Doutel
-
<joking/ribbing on> Wow, you're old ! "When I was young all we had to play with was a stick and a rock and we were damn happy to have it" <joking/ribbing off> I both agree and disagree. I think WPF is worth it, I also think that it's been make incredibly/unnecessarily difficult. I remember reading Petzold complain early on that MS was removing features that made it easier for programmers to hand code XAML. MS’s justification was that no-one would ever hand-code XAML. Having worked with both Blend and VS, I can’t see how anyone would produce any sort of interesting large project without hand-coding. The problem with XAML is it’s a bunch of different mini-languages and concepts wrapped in some XML. Building up intuition about how one part works doesn’t help (and sometimes hurts) you understand other parts. XAML is very powerful, fearfully verbose and a bit bizarre, which is a combination that doesn’t generally lead to something friendly. That said, if all you need is winforms functionality, it’s probably a better “win-forms” than winforms, just don’t use the designers, type the XML in directly and don’t attempt to do anything even remotely fancy. To me it feels like XAML and .NET (framework) were created by two different companies that each accidently created something that could be mad to work with the other.
ROFL! You're right! I AM old...! <W_C_Fields_Mode> "Go 'way, kid, ya bother me...!" </W_C_Fields_Mode> Agree; that "disconnect" between the Framework and the XAML is all the more acute if you don't have a firm grip on the XAML, and I don't. I know MS touts this "feature" as cool, because you can 'hand off the XAML' to a designer while the programmer works on the code, but as I said in my opening rant, how many of us really have that luxury? I mean, come on! You're lucky to get stick figures outta me...! ;-P Best Regards, Duane Doutel
modified on Wednesday, May 13, 2009 5:41 PM
-
Like most of you, I spend my days (and many nights) in the trenches, and have for nearly 30 years. I came up through assembly to C through C++ to C#, and a bunch of other stuff as side trips along the way. Having come from a place where there were NO IDE's to ease my pain, I'm supremely grateful for the ability to drag controls onto a form, smoosh 'em around, set some properties and be up and running with a skeleton to flesh out and deliver. I do NOT work with or have access to a graphic artist, nor do I wish to. Anyway, for the last several months on and off, I have attempted to come to grips with WPF, and I've finally arrived at the conclusion that it's just not worth the effort! In general, it's more work and more frustration for MUCH less functionality! Come on, MS! If I want to tinker endlessly with markup, I'll write in HTML, and likely have something that works in much less time and effort. To obtain the same level of useability I get with Windows Forms apps using WPF takes unbelieveable amounts of time and effort. Latest and greatest, my achin' posterior! Am I wrong? What am I missing here, folks?? Too busy for the MS merry-go-round, Duane Doutel
If I may be allowed to make a suggestion, have your tried Expression Blend? It's like an IDE that lets you build WPF interfaces and then pass the same project on to Visual Studio for coding.
-
If I may be allowed to make a suggestion, have your tried Expression Blend? It's like an IDE that lets you build WPF interfaces and then pass the same project on to Visual Studio for coding.
-
LINQ understands very well with SQL as i think you dont know that, LINQ is not for replacing SQL in fact you can use all of the features at database level in conjuntion with LINQ however most people missunderstands what LINQ is, behind the scenes LINQ is sql but i dont imagine how much time you take to build traditional code, and what LINQ does for you besides the control for what you get for the code in terms of the language of your choice that's priceless in time and performance
-
Maxxx_ wrote:
Surely it simply iterates collections looking for the criteria you're selecting on
No, that would kill performance, for a start. It actually transforms C# code into SQL, runs the SQL and converts the results back to C#.
Regards Senthil [MVP - Visual C#] _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro
-
I agree about the tools; between VS 2008 and Blend 2.1, and not having a large amount of time to spend in a chunk to grok it all, it's just not gel-ing for me. Add to that that in spite of having invested in several books, being an MSDN Premium subscriber, and reading a bunch of the stuff at CodeProject, the markup is neither A)introduced well at all, nor B) covered comprehensively in a single place. To top it off, it would seem that one of the supposed strengths of WPF is in the graphics department, and the extent of my graphics experience is in writing Windows printer device drivers many years ago (dithers, diffusions, etc.); in short, I'm no graphics designer. Best regards, Duane Doutel
modified on Wednesday, May 13, 2009 5:34 PM
ddoutel wrote:
my graphics experience is in writing Windows printer device drivers many years ago
Yup - been there too. And the way you work with Graphics in WPF is utterly different. I learned the most by reading through the XAML spec and test cases and then trying them by hand coding the XAML, using Blend and picking apart all of what it does, and just poking around inside as many samples as I could. Where it really worked well for me was in designing dialogs that stood up extremely well to users resizing them from ridiculously small to extra large. But I reckon that if it wasn't for the fact that I had spent a lot of time getting to grips with the XHTML spec I wouldn't have found it easy to read the XAML specs.
I just love Koalas - they go great with Bacon.
-
Not sure I understand youm but
chaosgeorge wrote:
behind the scenes LINQ is sql
is certainly not true.
___________________________________________ .\\axxx (That's an 'M')
Of course its true, all linq expressions translates to sql statements and are sent to server thats well known do a search
-
Sorry but that is rubbish. You speak as if running SQL over collections of objects just 'happens' - or are you just talking about Linq to SQL? which wasn't the question I was asking.
___________________________________________ .\\axxx (That's an 'M')
I was talking about LINQ to SQL, of course.
Behind the scenes, though, what does Linq do? Surely it simply iterates collections looking for the criteria you're selecting on.....It's not like when you have poorly performing SQL and you can add an index, or a foreign key and improve performance
That gave me the impression that you were talking about it too. My bad. Though in my defence, LINQ doesn't specify how the query is to be executed. LINQ to Objects, like you say, works by simply compiling the sub expressions into delegates and passing them as to the corresponding extension methods of IEnumerable>T< i.e. it doesn't go through IQueryable at all. Re-reading your post, I get the impression that you don't like the abstraction. If generated code is your problem, surely you must have run into that in C# 2.0, with anonymous methods and yield.
Regards Senthil [MVP - Visual C#] _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro
-
Like most of you, I spend my days (and many nights) in the trenches, and have for nearly 30 years. I came up through assembly to C through C++ to C#, and a bunch of other stuff as side trips along the way. Having come from a place where there were NO IDE's to ease my pain, I'm supremely grateful for the ability to drag controls onto a form, smoosh 'em around, set some properties and be up and running with a skeleton to flesh out and deliver. I do NOT work with or have access to a graphic artist, nor do I wish to. Anyway, for the last several months on and off, I have attempted to come to grips with WPF, and I've finally arrived at the conclusion that it's just not worth the effort! In general, it's more work and more frustration for MUCH less functionality! Come on, MS! If I want to tinker endlessly with markup, I'll write in HTML, and likely have something that works in much less time and effort. To obtain the same level of useability I get with Windows Forms apps using WPF takes unbelieveable amounts of time and effort. Latest and greatest, my achin' posterior! Am I wrong? What am I missing here, folks?? Too busy for the MS merry-go-round, Duane Doutel
WPF is difficult to learn I agree. I have spent the last 2 years developing a commercial WPF app and I have many many times wished for my winforms. However, change is good. The new stuff is better and we can create "cooler" apps. None of that might perk your interest but think about this: Winforms is not necessary dead but it is an old old man that no one is feeding any food. At some point you will either learn it or learn a new profession. If you start now you will be the one being hired in 2 years and not the winforms guy. I wouldnt have said this 6 months ago, but with VS2010 BUILT using WPF the validation is there, its not going away.
-
John Simmons / outlaw programmer wrote:
MS is trying to dumb it down so that anyone that's ever written HTML in a web page can feel empowered to write an enterprise-level application
That's exactly what I felt when I had my first experience with WPF. I also feel this way when I see tools that automate tasks you can do by writing code. That is why I also hate Reporting Services, that takes control out of you. Don't even mention infopath forms when I'm in the room. Even some some WinForms components I'd rather not use, and do it in hand. It is easier to debug and recover and again, gives you more control over the way things work (Like, SqlConnection, DataSet, etc)
Fabio Franco wrote:
I also feel this way when I see tools that automate tasks you can do by writing code
I'm all for tools that automate tasks, especially tedious tasks. I call it increasing productivity, not dumbing down. However, what we want is maximum flexibility. We also want the ability to get down and dirty when we need to.
Kevin
-
I remove all the toolbars too. You can never have too much usable screen real estate
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001I like the toolbars. Or rather I like specifically chosen buttons on the toolbar that aid my productivity. When I'm in heavy code-centric mode I just switch to full screen. I find I'm generally most productive when using a combination of keyboard shortcuts and mouse. I rarely bother with menus except when first learning a command. But devs are all different. Some years ago I was in a team of about 10 VC++ developers all using VC++ 6. No two devs were using the IDE in quite the same way and one or two were content with vi or some other editor, like Nemanja.
Kevin
-
It's quicker than the file menu to open a recent project. It needs to sepuku immediately after doing that however. :mad:
It is a truth universally acknowledged that a zombie in possession of brains must be in want of more brains. -- Pride and Prejudice and Zombies
dan neely wrote:
It's quicker than the file menu to open a recent project
Yes. But I also keep it closed most of the time. I add a button to the standard toolbar to re-display it if I need to.
Kevin