WPF--Why? No, Really!
-
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.