Whether it sucks or rocks...
-
what business need did you (or do you now) have that WPF solves for you (at least in theory)? Marc
Answer: None whatsoever. But mind you, we went and ported the entire show from WinForms. Not only was the result: a) slower b) more bloated c) less consistent d) sucked on fonts e) required designers and devs to talk (yikes!) f) crashed VS more than 5 times a minute at times g) wasteful exercise (apart from shining-up your CV) It simply looked like a joke at runtime overhead, appearance and all for few styling gimmicks (which you can all do in any tech with reflectino too damn easy to think). But WPF might be good for a toy demo here and there but complete apps you have to pursuade people with something like : 1) Browser (and one that people use in favour of another) 2) MS Office that doesn't suck as bad as OpenOffice 3) Android or Wii or PS3 app 4) Linux port (you know that thing that is free with all the things without licences and lock-ins) 5) 3D CAD like OpenGL does around 50 times faster than anything 3D WPF. Again, WPF, all yours.. see you at next MS upgrade stop (c1997, c1999, c2001, c2003, c2005 and c2007 so far.. Perhaps c4914, Windows will be writen in similar Redmond-RAM and-non-hardware-accelerated revolution and have around 1/985th of Google's customers but that might be a hard to see for people stuck on blogs.msdn.com and channel9-McCloud. One could argue that's why MS pays 1,000,000,000 dollars for 1% of cryptic PHP code and user-base these days..
-
what business need did you (or do you now) have that WPF solves for you (at least in theory)? Marc
None whatsoever and I've stopped drinking the MS Kool-aid (and did a long time ago if I'm honest). Hell, I still develop WTL and MFC apps (as well as a fair amount of pure C++ server stuff), and do you know what? They rock. They look good (the MFC Feature Pack ones look brilliant), they render quickly, they don't suck up RAM or gobble handles, they start quickly and I have never, ever had a single complaint about my UI from anybody (and I have written software that runs on tens of thousands of Windows PCs around the world). And this year, as soon as I have a good excuse, I am going to give Qt a go and start targeting ... gulp ... Linux and the Mac. Qt is, by all accounts, a superb C++ framework and I simply cannot wait to try it for myself. So, a massive *meh* to the latest MS framework. I really couldn't care less any more.
-
what business need did you (or do you now) have that WPF solves for you (at least in theory)? Marc
-
what business need did you (or do you now) have that WPF solves for you (at least in theory)? Marc
It would help in getting me work, but then again so would learning how to scrape dead animals off the road.
-
Rama Krishna Vavilala wrote:
costs associated with chicken parts
Yes, assembling chickens from parts can be quite complex. :laugh:
You really gotta try harder to keep up with everyone that's not on the short bus with you. - John Simmons / outlaw programmer.
-
Rama Krishna Vavilala wrote:
costs associated with chicken parts
Yes, assembling chickens from parts can be quite complex. :laugh:
You really gotta try harder to keep up with everyone that's not on the short bus with you. - John Simmons / outlaw programmer.
Actually, as a matter of fact, yes. The whole concept of disassembly and re-assembly costing is a big complex problem for cost accountants.
-
Actually, as a matter of fact, yes. The whole concept of disassembly and re-assembly costing is a big complex problem for cost accountants.
They should probably employ a Quantity Surveyor.
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.”
-
Rama Krishna Vavilala wrote:
As someone familiar with both WPF and WinForms for simple form based application. I can create the entire applications in the time it takes to recover from VS 2008 crashes.
With the data binding in WPF, and using a couple of helper tools (hint - read my reply to the post about why WPF rules and the tools I use), we can crank out LOB applications in no time at all. Here's[^] a quick post I wrote on how we develop with these tools.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
I still don't buy it. Note that I am not denying usefulness of WPF apps for a certain set of market. Your statement is true for certain applications but the moment you generalize and say that all applications can be rapidly developed with WPF, I don't think it holds true.
-
Rama Krishna Vavilala wrote:
Another point is that some people I know used WPF just because of the notion that WinForms will not be developed anymore.
and WPF is here to stay, forever and ever. there's no chance it'll be replaced by some other MS brainfart, in 18 months.
Well Silverlight is already here. Though similar to WPF it is a more recent fad.
-
what business need did you (or do you now) have that WPF solves for you (at least in theory)? Marc
-
Rama Krishna Vavilala wrote:
As someone familiar with both WPF and WinForms for simple form based application. I can create the entire applications in the time it takes to recover from VS 2008 crashes.
With the data binding in WPF, and using a couple of helper tools (hint - read my reply to the post about why WPF rules and the tools I use), we can crank out LOB applications in no time at all. Here's[^] a quick post I wrote on how we develop with these tools.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
Pete O'Hanlon wrote:
With the data binding in WPF
Alright, I'm going to play devil's advocate. I've written a generic data binder for WinForms that I use all the time, and I've written a routed event handler for WinForms too. Frankly, I don't see WPF providing useful features that actually can't be provided in WinForm applications, with, as you say, some helper tools. And that's the thing that does surprise me--that WinForm .NET doesn't actually have these useful tools built into it. But do we have to use WPF to get those useful features? Absolutely not, IMO. Marc
-
Rama Krishna Vavilala wrote:
costs associated with chicken parts
Yes, assembling chickens from parts can be quite complex. :laugh:
You really gotta try harder to keep up with everyone that's not on the short bus with you. - John Simmons / outlaw programmer.
I'm too chicken to try WPF (again) :-D
____________________________________________________________ Be brave little warrior, be VERY brave
-
what business need did you (or do you now) have that WPF solves for you (at least in theory)? Marc
The “business need” for WPF is weak; you generally won’t see WPF mentioned in a Business Requirements document. WPF falls under the category of “Supplementary Requirements”: • DirectX performance without having to know DirectX • Better graphics rendering (versus GDI+) • A “declarative” programming model • A more distinct presentation layer • Scales better to different display devices / resolutions
-
It would help in getting me work, but then again so would learning how to scrape dead animals off the road.
-
Rama Krishna Vavilala wrote:
Another point is that some people I know used WPF just because of the notion that WinForms will not be developed anymore.
and WPF is here to stay, forever and ever. there's no chance it'll be replaced by some other MS brainfart, in 18 months.
Apparently not there's talk of an even newer framework that will replace WPF verbosity. Let me find the link and I'll get back to you.
Software Kinetics - Moving software
-
what business need did you (or do you now) have that WPF solves for you (at least in theory)? Marc
In practice: take Word 2007 doc template, populate it with data from DB, and show to the user. Mind you, without Office components - WPF and Open XML SDK. :) Not quite MFC - XPS document view is provided by WPF only.
-
I still don't buy it. Note that I am not denying usefulness of WPF apps for a certain set of market. Your statement is true for certain applications but the moment you generalize and say that all applications can be rapidly developed with WPF, I don't think it holds true.
If you read my reply, I'm telling you why WE use it, no more no less. That was the question - why do you use it? For the applications we develop, my statements hold true. I don't state that all applications can be rapidly developed in WPF - there are large numbers of apps that I wouldn't touch with a bargepole with WPF, e.g. anything that demands realtime updating.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
Pete O'Hanlon wrote:
With the data binding in WPF
Alright, I'm going to play devil's advocate. I've written a generic data binder for WinForms that I use all the time, and I've written a routed event handler for WinForms too. Frankly, I don't see WPF providing useful features that actually can't be provided in WinForm applications, with, as you say, some helper tools. And that's the thing that does surprise me--that WinForm .NET doesn't actually have these useful tools built into it. But do we have to use WPF to get those useful features? Absolutely not, IMO. Marc
Marc Clifton wrote:
I've written a generic data binder for WinForms that I use all the time, and I've written a routed event handler for WinForms too
Yup, and if that works for you, great. You have the utilities that provide these features, so there's no compelling reason to use WPF. Ironically, the feature that people get excited about leaves me cold - I couldn't care less about flashy interfaces; generally our clients don't pay for flash, they pay for solid and reliable.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
Marc Clifton wrote:
I've written a generic data binder for WinForms that I use all the time, and I've written a routed event handler for WinForms too
Yup, and if that works for you, great. You have the utilities that provide these features, so there's no compelling reason to use WPF. Ironically, the feature that people get excited about leaves me cold - I couldn't care less about flashy interfaces; generally our clients don't pay for flash, they pay for solid and reliable.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
You say that there is no compelling reason to use WPF? Then why not go back to .NET 1.1 in Windows Me? My point is, I agree with you, having an application thats all flashy is not a good reason to do WPF. But how about being up to date with new technology like PRISM? And how about being able to do something (which you could do in WinForms too) faster? Take this for example. Why do you think MS is putting in so much effort into WPF and stop working on WinForms? I don't see any compelling reason not to use WPF. And I mean this not from the "it looks pretty". I mean this from the "i can do what i want in a shorter time".
Assumption is the mother of all f*ck ups.
-
what business need did you (or do you now) have that WPF solves for you (at least in theory)? Marc
Two primary issues on The Big New Thing™, my current project (as well as being the savior of humanity and more importantly, The Company): 1. The Company has a big push on for commonality of UI cosmetics between the software products created by the various divisions. We've got Mac stuff, Java stuff, and Windows stuff. The group that defined the common look-and-feel are primarily Java guys, so they defined an appearance that was easy for them to do. They told us at the time that they would be building WPF control libraries for us that we could re-use. PSYCH! In reality, we found out they're not building anything for us, six months after we committed to using WPF. We're stuck building our own implementation. At first glance, it doesn't look too hard. 2. My native applications used a home-grown layout engine. While it was fairly capable, it was tedious code to write, especially when the UI reconfigured a lot based on options. With WPF, you sprinkle the right amount of fairy dust, and it all happens, just like magic. My two 'business needs' are cosmetic, which just scratches the surface of WPF. We're finishing the UI framework for The Big New Thing™. When it's done, and we're actually populating the UI, we'll probably get more into the meat of it. Data binding, here we come... One additional note: We've transitioned directly from C++/MFC to C#/WPF, with no WinForms stop in between. That may explain my relatively pleasant experience thus far. I've had a lot more 'Ooohh... shiny!' moments than 'what the **** is this crap doing now?' moments.
Software Zen:
delete this;
Fold With Us![^]