WPF--Why? No, Really!
-
<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
-
Ya know, I'm the only programmer on my team that doesn't have the Start Page active and that has the last opened project load when VS is started. I'm also the only one on the team that codes for fun at home...
"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/2001John Simmons / outlaw programmer wrote:
has the last opened project load when VS is started
I set that option as well unless I'm regularly switching between different solutions. But I also use the Start page when necessary. Of course, you can also get recent projects from the file menu but it's more cumbersome and often less clear. Also you have to remember to increase the default options from 4 or whatever.
Kevin
-
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
pg--az wrote:
it seems difficult to believe you cant set-the-sel-item.
Actually you can set the selected item directly if you really want to, which isn't quite the way WPF is meant to be used - that's the point Josh Smith's article. 2 years ago I had a discussion about this very issue on the MSDN forums as seen here http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/99b6fdda-a599-4d4a-bf46-c59df589637e[^] You aren't meant to directly mess with the controls. Microsoft have a ViewModel toolkit here which might help http://wpf.codeplex.com/Wiki/View.aspx?title=WPF%20Model-View-ViewModel%20Toolkit[^] It's a different way to separate out the layers of your app, for the better I think as it separates the GUI toolkit code quite nicely from your app code.
-
pg--az wrote:
it seems difficult to believe you cant set-the-sel-item.
Actually you can set the selected item directly if you really want to, which isn't quite the way WPF is meant to be used - that's the point Josh Smith's article. 2 years ago I had a discussion about this very issue on the MSDN forums as seen here http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/99b6fdda-a599-4d4a-bf46-c59df589637e[^] You aren't meant to directly mess with the controls. Microsoft have a ViewModel toolkit here which might help http://wpf.codeplex.com/Wiki/View.aspx?title=WPF%20Model-View-ViewModel%20Toolkit[^] It's a different way to separate out the layers of your app, for the better I think as it separates the GUI toolkit code quite nicely from your app code.
John Stewien wrote:
Actually you can set the selected item directly if you really want to
Thanks for the clarification, now I won't go away blissfully misinformed.
John Stewien wrote:
it separates the GUI toolkit code quite nicely from your app code.
That's for sure a good thing.
pg--az
-
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?
Joseph Ceasar wrote:
Why push all the properties of a control to XAML when you can keep them in the properties window?
What? Properties aren't part of XAML - they are part of the classes. You are free to do it all in code if you desire. As far as editing property values in XAML, Intellisense probably works better there than any place else in VS. And the properties window is there if that's what you're used to. The VS visual editor, on the other hand, is incomplete and buggy IMO. Sure there's Blend, but I think most would agree that VS should have the same features as Blend... Not everyone has the means and/or the separation of visual and code designers (people) to want or need two separate tools.
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
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
I was very frustrated with WPF when I first started too, but now I’m loving it. I hardly ever use the tool bar or property sheet. I love WPF’s layout system. You never have to worry about tab order when you add a new control in the middle. My dexterity was always challenged when I had to drag a control into a group. Now I just insert a XAML element where I what it or if I put a control in the wrong place, I can just cut-and-paste the XAML code. When I’m debugging a complicated window, I cut out the more complex graphics until I discover the bug, then paste the graphics back in. The more I work with WPF the more I discover its power. The XAML editor is still immature. I least I’m hopping its InteliSense and outlining will improve.
-
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
I haven't used WPF in a real project, just played with to learn the new stuff. My 2 cents is to pick up a book. A good book can help overcome the deep learning curve with WPF. I bought a book called WPF unleashed, and I think it's worth the money(By the way, I didn't need a book to pick up Win Form). When I finished the book, I feel WPF is not as bad as I thought before. For XMAL, I think it should be treated as "Programing Language", not just a markup language to define the user interface. It's as important as C# in the WPF world in my opinion.
-
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
Duane, you are not kidding. WPF is painful, even with expression blend. My wife was a graphic artist, laying out marketing brochures. How she could function in an expression like tool (Corel Draw and Adobe Photoshop) has me stumped. Using Expression Blend to set the controls in your form is tedious at best. Understanding the styles is a very steep learning curve. It reminds me of programming to the QT gui, except that you can drag the controls and containers to where you want them rather than writing code. My company decided that WPF wasn’t worth the effort, so we chose to use a 3rd party software library from Infragistics. (See Infragistics.com and their window forms controls.) We needed a better data grid than was offered by Microsoft Win controls. These libraries are rather expensive, but if your employer has a deep pocket, then go for it. Another warning, these controls have many options and flags. Especially, the data grid.