Whether it sucks or rocks...
-
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![^] -
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/*)