How to sell WPF | The Coffeehouse

spivonious

Just had a small meeting with some other developers in my department demonstrating what WPF can do (binding, commands, control templates, data templates, layout managers).

They didn't seem too impressed and failed to see any gain over WinForms.

Our company is just starting to move over to .NET from VB6. Our main program is a VB6 MDI app that hosts "generic" forms with ActiveX controls on them. Basically this means that we just point a menu item to the new OCX instead of recompiling the main EXE. We also have a neat ClickOnce-like deployment system for it.

For .NET we're using COM interop to place WinForms controls on ActiveX controls which are loaded by the MDI app. Since WPF doesn't have COM interop, I've been placing a WPF control on a WinForms control on an ActiveX control.

Unfortunately we have a huge existing codebase of ActiveX controls so updated the main MDI app to be .NET isn't possible quite yet.

Any tips on how I can sell the others on using WPF over WinForms before we get too many WinForms controls?

figuerres
???

sounds like if i was in that spot is i would look to see what controls have wpf replcaements that are easy to locate, and if you use a 3rd party control set see if they have wpf versions of the same controls .... see if you can reduce the list to wpf only and how many you have to keep.

also i would look for cases where the old app used a custom control due to a limitation that wpf solves - like ui skinning or better databinding.

then if you can make a mockup of a chunk of the ui with wpf .... see if you can get say 90% "there" and then evaluate how much work to take that to the next stage.

when you know that then you will have a much better idea of what the issues are and if it's the right thing to push for or not.

I would look for some cases to show like:

the new stuff makes x,y and z less complex to code

or skin

or looks better

or you can eliminate some of the 3rd party bits with out of the box wpf and reduce licensing costs and dependance on them.

find them and make bullet lists of them.

if you find enoughn ammo and samples then you can tackle the sale.

spivonious

In reply to figuerres

#Oct 14th @ 8:37 AM

When I say controls, replace that with "applications hosted on a generic form but using the db connection from the MDI app". This MDI app is small by itself but hosts at least 100 applications inside of it. All through the magic of late-binding in VB6.

I think the main problem is that we have so few WinForms controls that even rewriting the VB6 in WinForms is an improvement. We only use one 3rd-party control and it's just a slightly more functional grid than the VB6 datagrid with an extremely small licensing cost. With .NET we're using only built-in controls.

I did show an example of a button that I made a new control template for so it would look like Superman's logo. In VB6 we just had a button with a Superman icon on it.

I think the main problem is that we'd be perfectly fine sticking with VB6. It works for what we want to do; everything else is just increased developer productivity and fancier graphics. If I hadn't been hired, I don't think .NET would even be discussed.

Maybe it's a lost cause. But I know I'm much more productive in WPF than I am in WinForms and VB6.

figuerres
???

In reply to spivonious

#Oct 14th @ 8:54 AM

what about targeting one or two of the "child" apps for a make over and just slowly work thru each of them?

also have a plan for how you would isolate the UI form the logic of the app.

regardless of WInForms, WPF or whatever.... when you make that separation you should be making the apps maint and test better and more able to chnage the UI seperate from the code - lose coupling between them woul be a good thing no mater what.

target productivity, target bug counts, target cost Vs. savings, target good eng. and arch. let snazzy graphics be the icing on the cake.

or build the solid business case first - as it were.

but if *you* do not see a clear gain then perhaps you are right... let it be if you can't clearly justify the move.

sometimes that is the best thing to do, the folks who count the money will learn to trust your calls when they feel that you are using good judgement and not just pushing the "new fashion".

developers do that a lot and bus. owners and Sr. Mrg. types tend to look for that after a while.

beeing able to say " I think this would be nice but not critical yet" can work in your favor later.

spivonious

In reply to figuerres

#Oct 14th @ 9:19 AM

Yeah, right now we're doing new apps in .NET, and rewriting old ones where it makes sense (where they require big changes, or are so fragile that even a small change can bring down a seemingly unrelated pieces).

I can see that WPF is the way to go, I just have trouble communicating that to others. And from the general response to it on the web, it seems that you really have to code with it to see the benefits.

sysrpl

I've looked at WPF a few times and always walk away with a sour taste in my mouth.

If you want to sell me on WPF, you need to sit down and recreate "notepad", with a status bar, menus (main and popup), find replace dialog, and a custom about screen. It would have to look like a normal application. I would then see how long it took and what steps you took to create it.

If it took you more than 20 minutes from start to finish to create it. I'd pass.

If you wrote it in less than 20 minutes, I'd investigate it further.

vesuvius
Das Glasperlenspiel

I'm a full time WPF developer, and our main application started off as pure WPF, but is now strewn with ActiveX and winforms controls.

It is just not feasible for any sizable application, that is mature to be written top to bottom in WPF.

Were it to be a new application, written after .NET 4.0 and Dev 10 comes out, then I'd say it is concievable that you can have a mostly WPF application. A typical enterprise grade application will almost always need to interop with COM/DCOM.ActiveX etc.

Windows 7 comes out in a weeks time [for the mortals], and that is written mostly in native code. People really neeed to stop thinking that great applications are not possible in winforms, because they are, that is why it is very difficult to impress windows forms developers, and why usually they have valid arguments as to why not to use WPF in some scenarios.

figuerres
???

In reply to sysrpl

#Oct 14th @ 9:48 AM

so sysrpl do you mean "the ui of notepad" or the whole real app with all the menus working?

very big diff. heck with winforms a *feature complete* notepad from scratch would i think need a bit more than 20 minutes to do it right.

now a fast one off hack that has most of notepad - yeah could be done i think, in winforms or wpf.

perhaps when i have time i just might see what i get and how long it takes.

Dexter

In reply to sysrpl

#Oct 14th @ 9:48 AM

Deciding if WPF (or any other UI framework) is good (or not) based on the time required to build a notedpad like application doesn't make any sense. Any decent UI framework will provide you with the basic ingredients of a notepad application: e plain text editor control, a menu, a status bar etc. All one needs to do is to put them together and that's just basic grunt work and in the end the time required to do it is more likely to depend on how fast he/she can think and type rather than on what framework/language is used.

Not to mention that WPF has many features that you won't need in a notepad application...

As for the original question:

It looks to me that no matter what you do you'll be stuck with a bunch of ActiveX controls for a long time. In that case I'm not sure what advantages WPF can bring. I don't think I'd care too much about WPF over WinForms in this situation.

figuerres
???

In reply to vesuvius

#Oct 14th @ 10:39 AM

two things:

1) tools - yes IMHO WPF and SIlverlight both have needed time for the tools and the foundation to mature. in then next 2 years we will see what happens.

2) pure? heck what point is there in that? what does it even really mean? we *ALWAYS* have to ballance things. every app i have ever seen that was of any real size has had to deal with some thing that was messy and not what the author wanted. that's part of the art of building great software - handling the challenges.

spivonious

In reply to Dexter

#Oct 14th @ 10:54 AM

"It looks to me that no matter what you do you'll be stuck with a bunch of ActiveX controls for a long time. In that case I'm not sure what advantages WPF can bring. I don't think I'd care too much about WPF over WinForms in this situation."

But since we're just moving to .NET, would it make sense to forego WinForms in favor of WPF, if only for the reason that it is "the future"?

ManipUni
Proving QQ for 5 years!

WPF is a good concept but that is all. I have zero interesting in developing apps for it. But I've never been told a GOOD reason to. Frankly this thread doesn't help. The OP should stick to ActiveX/Winforms. His reasons and the reasons provided just don't justify it.

He sounds like a kid with toys. It would hurt them in the long run.

spivonious

In reply to ManipUni

#Oct 14th @ 12:25 PM

Here's a reason. I'm sure you can do it in WinForms, but not with only a couple XAML lines.

I have a window that displays a list of instances of a custom class I made. The class is made up of a Group ID, Sample ID, Bottle Code, Bottle Count, and a list of Analyses.

In my window I have it displayed as a list box. Each item in the list box is an expander control. The expander header has the Group, Sample, Bottle, and Count displayed. When I expand it, the list of analyses is displayed in another list box.

Please tell me how this could be done in WinForms. I am by no means a WPF expert, yet this interface took me about 20 minutes.

LeoDavidson

In reply to spivonious

#Oct 14th @ 12:05 PM

I'd pick the framework which fits what you need best without worrying about which is more futureproof.

Windows UI frameworks seem to simultaneously last forever and have a short life expectancy. By that I mean that you can pick almost any of them and keep using it long past its retirement age but also, if history is anything to go by, whichever you pick will be put in the retirement home with all the others when the next one comes along (which can be more often than expected).

I might be wrong and WPF is here for the long-term, with all new ideas being put into it instead of a completely new framework built from scratch, but the history of UI frameworks has made me cynical. Smiley

I'm not saying you shouldn't use WPF, though. If it's the most suitable framework then use it, absolutely. Just don't worry about using another framework if one seems more suitable to the project or the team.

Dexter

In reply to spivonious

#Oct 14th @ 12:05 PM

But since we're just moving to .NET, would it make sense to forego WinForms in favor of WPF, if only for the reason that it is "the future"?

I'm not so sure that "is the future" is a good decision factor. It's true that WinForms is pretty much "done", you won't see any new features or bug fixes in WinForms for .NET 4, but I doubt that WinForms will be "obsoleted" any time soon.

It happens so that I'm currently working to upgrade a WinForms app to WPF. Do I like doing that? Yes. Is WPF perfect? No, it is not. Some WinForms controls have no WPF equivalent currently (NumericUpDown for example) and some WPF controls have various limitations (no "Expanding" event on TreeView/TreeViewItem for example).

PaoloM
Hypermediocrity

In reply to LeoDavidson

#Oct 14th @ 1:02 PM

I am really enjoying Silverlight right now to develop client apps. The learning curve is steep, coming from Winforms, but the rewards are very compelling.

For example, you can apply styles (kinda like CSS) to items all across the app and then control them from a single location. In my case, I want to have my app to have "night" and "day" modes, with dark or light backgrounds. Doing it in SL is literally one line of code, doing it Winforms... a bit more Smiley

But it all comes down to what you are proficient with and how much existing code you already have. It seems in your case that it's not worthy. New projects, on the other hand...

magicalclick

Well, even VS is moving towards WPF. Blend is completely off WPF. What WPF is good at is DPI scaling. Well, sadly for my app, it also scales my photo which will makes it blury. But, at least you can garantee no weird things happening when using different DPI. Especially like VS, VS 2008 on DPI scaling is terrible. The property box is like to gaint big, the font is like 24pt or something. And the tool bar, the WPF preview rendering, intelsence placement, error pop-up descriptions, and tons of stuff are out of place.

It does not have immediate benifits over WinForm, especially for less graphical applications. The databinding takes time to master. But, I can see with right tool like Blend and the right way to use those tool, it will be a lot easier and contextual (aka less coding) in the end.

spivonious

In reply to Dexter

#Oct 14th @ 1:23 PM

I have to agree that WPF isn't perfect, especially for being fairly old at this point (3 years?). Lots of controls that aren't built in are easily duplicated with a control template on the base control, or creating a new user control, but I agree that MS should have made it as easy as possible to move up from WinForms. Sure I can make a datagrid-esque control from a ListView, but I shouldn't have to. The datagrid in the WPF Toolkit was very buggy until a couple months ago.

But for me personally, the benefits outweigh the shortcomings. Binding and data templates especially. Styles are neat but we tend to stick with the default appearances as to not confuse our users.

I'm sure that if I could get the others here to spend the time to learn it and write their next app in it, they would see the benefits of WPF too (well maybe everyone but the lady who's been here for 25 years).