Whether it sucks or rocks...
-
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![^] -
what business need did you (or do you now) have that WPF solves for you (at least in theory)? Marc
Windows Forms 2.0 had a lot of quirks. For example, there was no Redo method for textbox-based controls. I bumped into it when I tried implementing the menu items I placed into my Edit menu. It seemed like there weren't any Windows API calls I could use to access the functionality either. WPF's textbox now has a Redo method, so it's trivial to access that functionality.
My GUID: ca2262a7-0026-4830-a0b3-fe5d66c4eb1d :) Now I can Google this value and find all my Code Project posts!
-
what business need did you (or do you now) have that WPF solves for you (at least in theory)? Marc
Here's how I explain it: Does management care what their work facilities look like? Some do, and some don't. An employer who goes for bare utility in an office or shop will probably do fine with a battleship gray WinForms App. But a lot of employers want to provide a relatively nice working space for their employees-- and a few want to provide a great one. They offer various rationales for doing so--productivity, morale, and so on. If an employer does invest in workspace quality, then their efforts can be undone by an incongruous online workspace--a battleship gray app looks cheap and cheesy in that environment, and that undermines the message management tries to communicate to their employees in their workspace design. WPF lets me (or a designer) tailor the UI of an app to match a client's overall workspace philosophy. If they want battleship gray, I can give it to them. But if they want something nicer, then I can give that to them, also. UI look and feel can be particularly important with younger workers. They grew up on the web, and by and large, they know what good UI design looks like. If they conclude that an app is cheap or cheesy, it will certainly affect how they work with it. It's kind of like putting a hand-painted sign on your front door.
David Veeneman www.veeneman.com
-
what business need did you (or do you now) have that WPF solves for you (at least in theory)? Marc
I'm writing a browser app which isn't out yet so I won't give details. I needed to do something which would have taken all year in Javascript, to build and to run. ActiveX and Java could be replaced by a little yellow bar at the top of the browser window in todays MS environment. WPF was the clear choice. That I could get some animation in there at low cost was a great bonus. It helps me visually imply what is going on as the UI is used and so makes it intuitive to use. So far so good. The XAML syntax was familiar to me as an HTML guy, the styling more flexible than anything CSS can do, the whole code model was intuitive and I was using it straight away. Its stable already, no undecipherable errors using it for the first time. All unlike Workflow Foundation which wasted lots of my time. Then there's the downside. It's sloooow. It can do amazing things but getting up to about 12 concurrent simple animations it loses its responsiveness. I've seen my dev machine run Crysis so I was expecting more bangs per buck out of WPF, that kinda sucked. So in summary, mostly rocks, fringe-sucks. The main business case I can give for using it is increased productivity in some scenarios (over heavily-involved DHTML for instance) and being able to offer more flexibility to your customers. It's not going to be long until everybody has seen a fade-in, or a realtime zoom, or a pretty glow radiate around something and will just expect you to be able to do that for them if they ask.
Matt Dockerty
-
The ones I see either say ASP.net or WPF (often both!). But I expect it's just idiots trying to list whatever they think is cool. Here's an example from today's batch o' crap:
* 5+ years fulltime .Net 2003 & 2005 development experience using VB.NET or C# including but not limited to ASP.net, Win Forms, n-Tier, .Net Framework 1.1, 2.0, 3.0 and experience with such technologies as WCF, WFF, ADO.NET, SOAP-based Web Services (WS/*) -
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.
WillemToerien wrote:
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".
Errm - you do know I'm a member of the WPF Disciples don't you? Marc declared why he could do things in Win Forms that I would do in WPF, and I know his history, e.g. he wrote MyXAML and has huge amounts of experience in declarative programming, so I know the level that he's pitching at. The point is, to me - the killer feature is the fantastic level of databinding, and if he can do that as well in Win Forms as I can in WPF, then that's great - there's no compelling business case to switch. Saying that, it's great that you're feeling the WPF groove.
"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.
-
what business need did you (or do you now) have that WPF solves for you (at least in theory)? Marc
Hmmmm, perhaps it "sucks rocks" ... I'll let you know after version 3 cause we all know that versions 1 and 2 of all MS products are alphas and you can't really tell about MS stuff till the version 3 beta's start showing up. I think it's because they don't try to start using it in-house for a while and when they do they "discover" things :-D
-
what business need did you (or do you now) have that WPF solves for you (at least in theory)? Marc
applications-the-way-the-user-always-wish-to-look-like-but-could-not-never-seen-real-improving-UX scenarios thats what WPF solves
-
what business need did you (or do you now) have that WPF solves for you (at least in theory)? Marc
Marc Clifton wrote:
what business need did you (or do you now) have that WPF solves for you (at least in theory)?
All my software development UI needs. With WPF, and its little sister Silverlight, I get UI work done way faster than I ever did before... I now spend a significant percentage more time on business/data logic. I skipped Windows Forms and came directly from MFC...MFC was killing me in time spent on UI programming. There was a learning curve, because it's NOT the old Win32/HWND UI system. Taking the time to read the entire WPF SDK twice before I even started using it helped, and was really worth the time.
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
what business need did you (or do you now) have that WPF solves for you (at least in theory)? Marc
Short answer: I wrote something which is a bit like a web browser, displaying custom data that can be anything from text to video. The layout and style of the visuals needed to change based on some analysis of the data + some rules that were sent to the player by the backend. This thing is now deployed in thousands of locations around the world. IMHO, I'd have to be a programming uber-prodigy to accomplish what I did, with a lesser framework than WPF. WPF allowed me to focus strictly on the data and rule analysis. The designers came up with nice presentation templates, I put in place the appropriate data bindings and converters, and BAM - it just worked, unbelievably fast and smooth. I come from a long Un*x/Mac background, used to be 100% ABM, but what those guys did in WPF is, to me, the application programmer's holy grail.