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
U should look for WPF features, is evolution in UX, windows forms was a basic ui platform but now you can do anything you can imagine for ui with WPF from simple buttons to video, multimedia, 3D and DirectX controls and visuals not to mention flow documents where you can manipulate any openXML format like word documents, now days interfaces should be more usable for the user because of the so much information they handle good UX translates to better Software
-
Maybe I'm getting old and resistant to change! But let us know if you find compelling arguments for moving over to WPF/linq. As a business app developer I'm not so much charmed by fancy looks or elegant looking short syntax, I just need to get the job done quick and not run into an obscure dead (albeit advanced) end (like if you started on linq to sql? Tough luck!).
Wout
I think you should really look at what LINQ offers (i think you know lambda expressions and linq to objects already) in conjuntion with Entity Framework and ADO.NET Data Services it's a new way to handle data in todays data centric applications, no way you get the job done faster with traditional sql techniques than using correctle these technologies
-
ddoutel wrote:
What am I missing here, folks?
I suspect that XAML, unlike HTML, was designed to be machine-generated (good luck finding a machine to generate it just the way you want it... Anyone doing forms entirely in Expression yet?). WPF however, can be used without XAML, and stands a reasonably good chance of being The Way Forward when it comes to graphics APIs on Windows. At least until the Windows team puts their foot down and completely refuses to use it. BTW: the correct place for rants is The Soapbox 2.0
Shog9 wrote:
BTW: the correct place for rants is The Soapbox 2.0
Or bill@windows.com :-D
-
I'm just starting to use Linq in teh real world, having avoided it for a while. My opinion (FWIW) Linq is great for shortening the amount of code you need to write when dealing with collections of objects. I suspect it is great for dealing with XML (haven't tried it, but have always wanted to be able to find XML elements simply using some SQL-Like syntax) Behind the scenes, though, what does Linq do? Surely it simply iterates collections looking for the criteria you're selecting on - it doesn't (I presume) have some ingenious way of adding indexes, binary trees etc. to objects to increase search performance. I always get a little nervouse when something is essentially generating code for me, that I can't easily look at. It's not like when you have poorly performing SQL and you can add an index, or a foreign key and improve performance... And Linq to SQL IMHO is another 'gimick' that makes it look like a RAD tool, but isn't really good to be used in the real world where (again, my preference) using Stored Procedures rather than generated SQL gives me maximum control.
___________________________________________ .\\axxx (That's an 'M')
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
-
CKnig wrote:
but maybe this changes with age
Probably, I can't just start learning everything new that's out there, there's too much change to digest. So I have become picky about what I think makes sense and what does not. I like many parts of the .NET framework, I like win forms, ASP.NET, .NET remoting, WCF seems ok too.
CKnig wrote:
And I just can't understand how you can not like .NET 3.0/3.5 as a progammer
I should have been more concise in my wording here: I do like most of the C# 3.0 changes, but I don't see the need for a lot of the framework additions. From a user perspective I don't see why I'd need a 200 MB download for .NET 3.5, as opposed to about 22 MB for .NET 2.0. My win forms apps are just fine in .NET 2.0, for the user there's just no compelling reason to require that extra 180 MB download. Also I can use C# 3.0 fine with .NET 2.0 and compile into a .NET 2.0 application, so for the time being (next one or two years) I'm writing apps in this configuration.
Wout
Well im a programmer that really uses alll of C# 3.0 features in real world projects, what you should do with C# 2.0 you can do it better, more elegant, and more compact with C# 3.0 features, i think you are giving your user more mb for your code and less value than just that tinny difference within .net 2 and .net 3.5 sizes (and in todays storage thats not to worry about! comn)
-
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?
First, i thing you folks are too old to understand the advantages of WPF they are so many you have not giving your time to study it in deep as i can see Second properties have intellisense in xaml besides there is a properties pannel for alll properties of the control Third! you can bind data to a grid and lay it out the way you need at design time! however using the designer to do that is just for noobs i code every single part of the interface in xaml and believe is faster than layout with the designer, Fourth. WPF controls are extremley mature now, and you should take a look at WPF toolkit Fifth. If XAML gets too big well you are a noob programmer who places alll of the UI in a single xaml/cs file! you should learn a bit about Model-View-ViewModel Pattern or even better Composite Application Library from Microsoft
-
Come on now! You know you've always wanted to put a movie on the surface of a button! Who hasn't?
MattBerry wrote:
Come on now! You know you've always wanted to put a movie on the surface of a button! Who hasn't?
If that's intended as sarcasm you miss the point: you can if your app needs it. Anything the graphics engine can do can be encorporated into your GUI. The look and feel of your app isn't limited by the imagination of some poor slob at Microsoft who, in times past, dictated the visual aspects of the button control. You have complete control.
-
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
ddoutel wrote:
I've finally arrived at the conclusion that it's just not worth the effort!
I tried WTF... oops, I mean "WPF" a couple of times. Went back to Windows Forms. I'm a hobby-coder, so this stuff is supposed to be fun. Headaches aren't fun. :-D
-
I'm just starting to use Linq in teh real world, having avoided it for a while. My opinion (FWIW) Linq is great for shortening the amount of code you need to write when dealing with collections of objects. I suspect it is great for dealing with XML (haven't tried it, but have always wanted to be able to find XML elements simply using some SQL-Like syntax) Behind the scenes, though, what does Linq do? Surely it simply iterates collections looking for the criteria you're selecting on - it doesn't (I presume) have some ingenious way of adding indexes, binary trees etc. to objects to increase search performance. I always get a little nervouse when something is essentially generating code for me, that I can't easily look at. It's not like when you have poorly performing SQL and you can add an index, or a foreign key and improve performance... And Linq to SQL IMHO is another 'gimick' that makes it look like a RAD tool, but isn't really good to be used in the real world where (again, my preference) using Stored Procedures rather than generated SQL gives me maximum control.
___________________________________________ .\\axxx (That's an 'M')
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
-
First, i thing you folks are too old to understand the advantages of WPF they are so many you have not giving your time to study it in deep as i can see Second properties have intellisense in xaml besides there is a properties pannel for alll properties of the control Third! you can bind data to a grid and lay it out the way you need at design time! however using the designer to do that is just for noobs i code every single part of the interface in xaml and believe is faster than layout with the designer, Fourth. WPF controls are extremley mature now, and you should take a look at WPF toolkit Fifth. If XAML gets too big well you are a noob programmer who places alll of the UI in a single xaml/cs file! you should learn a bit about Model-View-ViewModel Pattern or even better Composite Application Library from Microsoft
Sorry, but the simplicity of creating a simple GridView in WinForms can't be beat. Drop a grid on a form. Click on the grid to create a new data source and bind it. If you know how to do it in a simple easy way in WPF please tell me. I've been at it for 3 days to no avail. I got the WPF Toolkit and the WPF DataGrid. I must admit that it was very easy to do the data binding in C#. All it took was 1 line of code to set up the DataContext for the form. As far as the XAML goes it was not that easy. Yes, ItemsSource is in the intellisense list but that's about it. I had to do some googling and watch some videos in order to figure out the "{Binding Path={}}" part. Now I want to define some of the columns in my GridView. It would be nice to be able to bind during design time so that I can see what the layout would look like (same as I would do it using WinForms). I can't find any real help on that..... Another issue is related to the XAML intellisense. Where is the tooltip help that pops up with some guidance as to what each property, method and node does? We do have that in the code behind but not in XAML. In other words, we now have to learn a whole new language (XAML) in order to lay out our forms. We never had to do that with any visual designer up to this point. Don't get me wrong. I do like the whole concept of XAML. To be really usefull, I should be able to everything using the property pages without having to resort to XAML. The advantage is that grunt of the work will be done visually and you would go to XAML in order to tweak. This is the way that ASP.net development works right now. Lastly, since the layout is totally separate from the code (C# or VB), it would be nice to have the option to deploy the application with the XAML in a separate file. This way you could do some changes to the layout without having to recompile the whole app.
-
Sorry, but the simplicity of creating a simple GridView in WinForms can't be beat. Drop a grid on a form. Click on the grid to create a new data source and bind it. If you know how to do it in a simple easy way in WPF please tell me. I've been at it for 3 days to no avail. I got the WPF Toolkit and the WPF DataGrid. I must admit that it was very easy to do the data binding in C#. All it took was 1 line of code to set up the DataContext for the form. As far as the XAML goes it was not that easy. Yes, ItemsSource is in the intellisense list but that's about it. I had to do some googling and watch some videos in order to figure out the "{Binding Path={}}" part. Now I want to define some of the columns in my GridView. It would be nice to be able to bind during design time so that I can see what the layout would look like (same as I would do it using WinForms). I can't find any real help on that..... Another issue is related to the XAML intellisense. Where is the tooltip help that pops up with some guidance as to what each property, method and node does? We do have that in the code behind but not in XAML. In other words, we now have to learn a whole new language (XAML) in order to lay out our forms. We never had to do that with any visual designer up to this point. Don't get me wrong. I do like the whole concept of XAML. To be really usefull, I should be able to everything using the property pages without having to resort to XAML. The advantage is that grunt of the work will be done visually and you would go to XAML in order to tweak. This is the way that ASP.net development works right now. Lastly, since the layout is totally separate from the code (C# or VB), it would be nice to have the option to deploy the application with the XAML in a separate file. This way you could do some changes to the layout without having to recompile the whole app.
It's because of the simplicity of windows forms to do what you mention of drag and bind that exists binding in xaml, you can achieve any combination of bindings in xaml deep in the visual tree as you want something winforms has not, datatemplates to show the data just the way you want (a pain if you do it in code behind) hierarchical data templates, triggering, styling all of that is a lot easier to do in xaml than in code. For the intellisense well certainly is not the best of intellisense however thats going to be better in VS2010 as far as i know, however intellisense now is pretty good in xaml because xaml was not intended to be for busness logic so you dont need more really, just learn a bit of the binding syntax and you are done, the most of the properties fo the controls are self explanatory i dont think with intellisense guidance you know exactly what something does, the documentation is for that. <blockquote class="FQ"><div class="FQA">Joseph Ceasar wrote:</div>In other words, we now have to learn a whole new language (XAML) in order to lay out our forms. We never had to do that with any visual designer up to this point.</blockquote> Believe me its worth it besides its so much like XML in fact is exactyle the same thing (i bet you know xml) just different purposes just like html is for web interfaces, XAML is for UI WPF/silverlight interfaces i dont think its a huge learning curve from there
Joseph Ceasar wrote:
Lastly, since the layout is totally separate from the code (C# or VB), it would be nice to have the option to deploy the application with the XAML in a separate file. This way you could do some changes to the layout without having to recompile the whole app.
Thats not concern of the tool is up to your programming skills, xaml/codebehind is a simplicity for new developers so you dont get lost as soon as you get your hands on it, its just common point with windows forms. Actually if you want to separate the UI from the code you must implement as i mentioned befoere Model-View-ViewModel like patters or use / or use in conjunction the Composite Application Library guidance that really encapsulates the UI and leaves the business logic apart
-
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