Backgrounder needed. Why WPF

  • Thread starter Thread starter Just_a_fan
  • Start date Start date
J

Just_a_fan

I have been through two books where they talk about the (almost)
parallel control set for WPF and VB. They go through the small
difference and talk about everything going on a form but what they don't
say is...

WHY WPF?

What did we get by having a (almost) parallel design palette. If the
features were so good, why not just fold them into the parallel controls
in VB?

This makes for another set of hundreds of things to remember and I can't
see the overriding benefit.

Possibly there is a White Paper on this somewhere or someone in the know
can say why. Wrox book talk about the what but not why this duality
came about.

Thanks for any help with this. I can't help but think that two
competing groups of designers got to load their almost identical but
incompatible stuff into the same IDE. Just seems odd to me. Anyone
else?

Mike

-----------------------------------------------------------

There are a variety of enhancements to the WPF Designer that are not
available in the Windows Forms Designer. These enhancements include:

Margin lines and stubs: Margin lines around each control indicate that a
margin has been set for that control. A margin stub indicates that no
margin has been set for that control edge.

Zoom control: The Zoom control appears in the upper-left corner of
Design view and allows the developer to zoom in or out on the design
surface to perform exact adjustments.

Snaplines: While snaplines appear in both the WPF Designer and the
Windows Forms Designer, in the WPF Designer they also display exact
values. In addition to displaying control alignment, snaplines also show
text alignment for text-based controls. For more information, see How
to: Align to Both Text Baselines and Margins.
 
Why WPF?

It may be parallel for now, but prepare for it to surpass WinForms in the
near future. MS have clearly opted to invest into WPF, XAML, Silverlight,
XPS, and all the other new 3.5 technologies as heavily as they can (someone
at Adobe pissed them off maybe?) so in many respects it makes sense to start
investing into it yourself and get ahead of the game.

In terms of coding advantages, it makes the separation of the GUI from the
business logic a lot more clear cut, it actually makes more sense to define
a UI in markup rather than code, the presentation capabilities are
impressive, front end performance is generally better, customisation &
skinning of UI is a lot easier and more powerful, you can do more with
standard controls by editing templates without having to resort to creating
custom controls, and it makes conversion of an app from the desktop to the
web a lot simpler.

But, why *not* WPF...?

First off, despite the 1.0 moniker, it simply is not finished. Some
controls are missing, others don't support the full set of functionality
you've probably come to expect from doing WinForms development, and there's
a bit of a learning curve associated with it. I was all ready to start
coding a simple explorer style app until I realised that the TreeView
doesn't have a rootlines property, and to implement such a simple thing
manually required over a hundred lines of template modifying XAML that I
didn't really understand, and even then it didn't work perfectly. Ditto for
another app of mine that I wanted to rewrite in WPF - right up until I found
that the WebBrowser control and DateTime picker don't exist, and would
require WinForms interop.

If I were you, I'd invest the time in learning it now so that you're ready
and tooled up for later in the year when MS will *hopefully* fix these
shortcomings with an update.

-Alex
 
Back
Top