WPF--a threat to WinForms?

[raylopez99]

Here I am learning WinForms and two months into it I learn there's a
WPF API that is coming out. Is this WPF out yet, and is it a threat
to WinForms, in the sense that all the library routines I memorize and/
or familiarize myself in WinForms will disappear in WPF? I did note
in one early version of C#, the non-generic "ArrayList" was replaced
by the generic and template <> based List, but that kind of change is
not a big deal. If WPF makes these trivial changes I can deal with
it, otherwise not.

I see WPF uses some variant of XML in lieu of binary serialization,
which is no biggie, but if it does away with the drag and drop Wizards
interface of Visual Studio 2008 C#, with IntelliSense, I will be
bummed (I doubt it).

Also is C# going to be supported in WPF? I suppose so.

Any thoughts appreciated. Seems to me, as a newbie coming from a C++
background, that C#.NET is a lot of just familiarizing yourself with
entry points (where to put your code and what the preferred class
library functions to use), which is made much easier with the 'partial
classes' and wizard non-programmic instantiation of objects.

Also it seems to me (intuition) that ASP.NET will be more affected by
WPF, since ASP.NET seems more like a script/macro language and/or not-
strongly typed (no strong IntelliSense, at least when I checked it out
a few years ago).

RL


Windows Presentation Foundation
From Wikipedia, the free encyclopedia

This subsystem is a part of .NET Framework 3.0
The Windows Presentation Foundation (or WPF), formerly code-named
Avalon, is a graphical subsystem in .NET Framework 3.0 (formerly
called WinFX)[1] and is directly related to XAML.[2] WPF is included
with Windows Vista and Windows Server 2008, and is also available for
Windows XP Service Pack 2 or later, and Windows Server 2003. It
provides a consistent programming model for building applications and
provides a clear separation between the user interface and the
business logic. A WPF application can be deployed on the desktop or
hosted in a web browser. It also enables rich control, design, and
development of the visual aspects of Windows programs. It aims to
unify a host of application services: user interface, 2D and 3D
drawing, fixed and adaptive documents, advanced typography, vector
graphics, raster graphics, animation, data binding, audio and video.
Although WinForms will continue to be widely used, and Microsoft has
created only a few WPF applications, the company promotes WPF for line-
of-business applications.[3]
Microsoft Silverlight is a web-based subset of WPF that enables Flash-
like web and mobile applications with the same programming model
as .NET applications. 3D features are not supported, but XPS and
vector-based drawing are included.

 

[Family Tree Mike]

WPF is included as part of VS 2008. Have you tried to build a "Hello,
world!" application? I assume some people love WPF, but I don't care for
it. You can drag controls onto the form as with winforms. You can code in
both VB.Net and C#.

Here I am learning WinForms and two months into it I learn there's a
WPF API that is coming out. Is this WPF out yet, and is it a threat
to WinForms, in the sense that all the library routines I memorize and/
or familiarize myself in WinForms will disappear in WPF? I did note
in one early version of C#, the non-generic "ArrayList" was replaced
by the generic and template <> based List, but that kind of change is
not a big deal. If WPF makes these trivial changes I can deal with
it, otherwise not.

I see WPF uses some variant of XML in lieu of binary serialization,
which is no biggie, but if it does away with the drag and drop Wizards
interface of Visual Studio 2008 C#, with IntelliSense, I will be
bummed (I doubt it).

Also is C# going to be supported in WPF? I suppose so.

Any thoughts appreciated. Seems to me, as a newbie coming from a C++
background, that C#.NET is a lot of just familiarizing yourself with
entry points (where to put your code and what the preferred class
library functions to use), which is made much easier with the 'partial
classes' and wizard non-programmic instantiation of objects.

Also it seems to me (intuition) that ASP.NET will be more affected by
WPF, since ASP.NET seems more like a script/macro language and/or not-
strongly typed (no strong IntelliSense, at least when I checked it out
a few years ago).

RL


Windows Presentation Foundation
From Wikipedia, the free encyclopedia

This subsystem is a part of .NET Framework 3.0
The Windows Presentation Foundation (or WPF), formerly code-named
Avalon, is a graphical subsystem in .NET Framework 3.0 (formerly
called WinFX)[1] and is directly related to XAML.[2] WPF is included
with Windows Vista and Windows Server 2008, and is also available for
Windows XP Service Pack 2 or later, and Windows Server 2003. It
provides a consistent programming model for building applications and
provides a clear separation between the user interface and the
business logic. A WPF application can be deployed on the desktop or
hosted in a web browser. It also enables rich control, design, and
development of the visual aspects of Windows programs. It aims to
unify a host of application services: user interface, 2D and 3D
drawing, fixed and adaptive documents, advanced typography, vector
graphics, raster graphics, animation, data binding, audio and video.
Although WinForms will continue to be widely used, and Microsoft has
created only a few WPF applications, the company promotes WPF for line-
of-business applications.[3]
Microsoft Silverlight is a web-based subset of WPF that enables Flash-
like web and mobile applications with the same programming model
as .NET applications. 3D features are not supported, but XPS and
vector-based drawing are included.

 

[Marc Gravell]

Is this WPF out yet

Yes; for a long time - it is part of .NET 3.0; however, most surveys
etc show that uptake has been slow (but ever-increasing in popularity
for .NET UI work).

, and is it a threat to WinForms, in the sense that all the library routines I memorize and/
or familiarize myself in WinForms will disappear in WPF?

By not being bound into the old windows API it gets some advantages,
as well as being directly comparable to Silverlight etc. But it is a
completely different model to the windows controls. That said, the
general concepts of displaying data to the user (and interacting with
the user and data etc) remain intact - it is just the implementation
details that change.

I see WPF uses some variant of XML in lieu of binary serialization,
which is no biggie, but if it does away with the drag and drop Wizards
interface of Visual Studio 2008 C#, with IntelliSense, I will be
bummed (I doubt it).

Well, .NET winforms don't use much binary serialization either - the
designer does code generation with a relatively small amount of resx
binary.

Also is C# going to be supported in WPF?  I suppose so.

The two are orthogonal concepts - but yes, you can interact with WPF
via C#.

Also it seems to me (intuition) that ASP.NET will be more affected by
WPF, since ASP.NET seems more like a script/macro language and/or not-
strongly typed (no strong IntelliSense, at least when I checked it out
a few years ago).

ASP.NET will hardly be *at all* affected by WPF. ASP.NET is a server-
side http framework. BAML offers client-side WPF support, but only on
Windows - however, Silverlight is multi-client and has lots of
potential for client-side rich browser apps. Not quite the same as
WPF, but very similar and designed with smart-client browser apps in
mind.

Marc

 

[not_a_commie]

 If WPF makes these trivial changes I can deal with

it, otherwise not.

Holy crap, dude. Is this a joke? Come out of the closet. Plug your
computer into the internet. You seem like the kind of person who
doesn't deal with change well, which would make a job as a programmer
particularly difficult for you. WPF has been pushed with Vista for
several years now. API info on it has been available for at least
three years. WinForms goes back 7 years, although the format of the
WinForms library is similar to GUI APIs available years before that.
WPF is the technology intended to replace WinForms. You can file bugs
on WinForms with MS, but they won't get fixed. The future is WPF. And
it rocks, really. I've been coding WPF for a year and loving it. WPF
has some issues, but WinForms has ISSUES. WPF has had a lot of design
work. And overall I think it has come together quite well.
Notwithstanding that, I assure that the WinForms API won't disappear
any time soon.

I see WPF uses some variant of XML in lieu of binary serialization

I have no idea what you are talking about here. Well, actually, I
think you're talking about XAML. However, I think you're comparing
apples and oranges.

 

[raylopez99]

Yes; for a long time - it is part of .NET 3.0; however, most surveys
etc show that uptake has been slow (but ever-increasing in popularity
for .NET UI work).

Thanks. Well your opinion is not inconsistent with Pavel Minaev's
opinion, from another thread, which I reproduce below. And I guess
BTW Silverlight is MSFT's variant of Ajax and/or is like J++ was to
Java. or something. Alphabet soup!

RL

Will the WinForms API/libraries be mapped to WPF?

Not likely. WPF is its own, quite distinct, API, and in large part
its
benefits are due to that API. There's very litte if anything to be
gained from reimplementing WinForms on top of WPF. In fact, I doubt
it
is even possible to do so by remaining backwards-compatible, since
WinForms has some close ties to stuff such as Win32 event loop
(Control.WndProc, message filters etc). Since WPF uses its own
system,
and WPF controls are not Win32 window handles (except for the top-
level ones), I don't see how a faithful reimplementation could
possibly work.

Or do we have to
learn another 1000 routines to do the simpliest stuff, in your
opinion?

Yes, though gladly, this time it's pretty well thought out. WinForms
was very similar to Delphi's VCL and the nameless VB6 UI toolkit, and
both are spawns of mid-90s. It's been more than 10 years now; it's
time to move on to resolution-independent accelerated graphics,
proper
font rendering (kerning etc), dynamic layouts, and data binding
throughout as a proper way of implementing MVP. WPF offers all that.
In fact, to the best of my knowledge, the only other UI toolkit that
is as advanced is Apple's Cocoa, while Gtk and Qt are lagging behind
(in contrast to WinForms, compared to which both Gtk and Qt are light
years ahead - if only because of proper, working dynamic layouts).

That's interesting. Vista does not have 3.5, which presumeably will
be used for WPF, while LInux distros mostly have Qt. Got it.

Microsoft has promised to roll out 3.5 SP1 on Windows Update as a
recommended update (which means it is selected by default) for all
machines that have 2.0 or higher already installed, though they
didn't
specify any date - just that they're going to do it "some time in the
future". This means that most Vista machines will be auto-updated,
but
not all XP ones.

 

[Marc Gravell]

And I guess BTW Silverlight is MSFT's variant of Ajax

and/or is like J++ was to Java.

Then you're not very good at guessing nor searching.

Well your opinion is not inconsistent with Pavel Minaev's opinion

I don't see any inconsistency. Feel free to spell it out...

Marc

 

[Marc Gravell]

Well your opinion is not inconsistent with Pavel Minaev's opinion

Sorry RL - my bad; I misread this as "is not consistent"; genuine
apology. Re Silverlight, it is more like Microsoft's variant of Flash.
You can get an idea from the Hard Rock site: http://memorabilia.hardrock.com/

Marc

 

[Jeff Gaines]

The future is WPF. And
it rocks, really. I've been coding WPF for a year and loving it.

Any chance of some links to any good examples you've come across in your
research? Data and file management would be good.

I managed to find a couple of quite old and basic samples but nothing to
get excited about sadly. I have also been unable to turn unclear-type off
for WPF (although it's off for the system) and haven't been able to find
out anything on how to do that.

 

[Tim Jarvis]

Yes; for a long time - it is part of .NET 3.0; however, most surveys
etc show that uptake has been slow (but ever-increasing in popularity
for .NET UI work).

Personally I think that the barrier to entry is still to high.

It's simply still too hard to do simple things, sure complex things are
possible, but simple things should be simple. I also think that the aim
of formally splitting UI work and domain model coding work up between
graphic artists and coders is naive, except in very rare cases this
simply will not happen (at least that's the case here in Oz) so having
to fire up both Blend and VS side by side is a non-starter for most.

I personally love the idea behind WPF, but I think that the right
tooling to make this technology attractive to the mainstream is still a
couple of years away.

Cheers Tim.

 

[Alvin Bruney [ASP.NET MVP]]

It's simply still too hard to do simple things, sure complex things are
I agree with this. However, once the learning curve tax is paid, it gets
easier.

of formally splitting UI work and domain model coding work up between
graphic artists and coders is naive, except in very rare cases this

Naïve is not the right word here at all. This model is separation is a
proven and valid approach in the web world. There's absolutely no reason why
it won't gain traction in the windows world given that the line between web
and windows is not even visible anymore, let alone blurred.

--

Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
Download OWC Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $15.00
Need a free copy of VSTS 2008 w/ MSDN Premium?
http://msmvps.com/blogs/alvin/Default.aspx

 

[JDeats]

WPF has been a long time coming and is a response to many things. I've
been following the evolution of XAML since at least 2004. It came into
being because Microsoft needed a vector based run-time to compete with
marketshare Adobe Flash was getting. Adobe actually hired Mark Anders
from Microsoft's ASP.NET team to head up what became Adobe Flex which
is also an XML based markup aimed primarly at creating RIA (Rich
Internet Applications) but with the capability of the compiled code
running outside a browser a a cross-platform desktop application (see
Adobe AIR). There are other XML based RIA frameworks as well. XAML/WPF/
Silverlight (confusing isn't it).

Are ASP.NET WebForms threatened by WPF/Silverlight? Absolutely. Just
like classic ASP was threatened by ASP.NET, we've always moving
forward. The problem ASP.NET (PhP, RoR, JSP, etc...) is that they
output HTML, CSS and JavaScript markup. HTML itself has become a
bloated mess, with companies investing too much money trying to build
robust desktop grade applications on top of script and markup based
frameworks never designed to tackle the job they are being put to use
for. The new RIA XML based markups (such as XAML) offer a clean
slate.

The only problem now is that there is no unified standard (in spite of
Microsoft's efforts to standardize XAML, which they have). Adobe's
Flex has the largest market share and Silverlight has only recently
started to make some waves. It's a long road ahead for these
frameworks, but I sure hope one of them represents the future because
I believe they represent cost-effective ways to deliver robust
applications. I would like to say there will always be cases where it
would make more sense to use HTML/CSS/JavaScript based solutions, but
the trurth is the HTML/CSS/JavaScript stack is destine to become
legacy technology.... Web browsers will have to support it for
backwards compatibility sake and I'm sure billions of sites will
remain, but there will come a point when most new development is not
HTML/CSS/JavaScript based.

WinForms is less threatened by WPF because of the nature of WinForms
applications. In my opinon Enterprise desktop applications already
have a very rich framework with WinForms and quite effective set of
controls to get the job done. From an architecture perspective I don't
see WPF having a lot to offer over WinForms to most enterprise desktop
application developers, but Enterprise web applications certainly
could benefit from the paradigm WPF offers, it's a very dramatic,
empowering shift for a web developer.

WPF on the desktop just gives developers wanting to unify the web and
desktop experience an option. Over time it will probably replace
WinForms, but I could see WinForms sticking around for a few
generations.

 

[raylopez99]

WinForms is less threatened by WPF because of the nature of WinForms
applications. In my opinon Enterprise desktop applications already
have a very rich framework with WinForms and quite effective set of
controls to get the job done. From an architecture perspective I don't
see WPF having a lot to offer over WinForms to most enterprise desktop
application developers, but Enterprise web applications certainly
could benefit from the paradigm WPF offers, it's a very dramatic,
empowering shift for a web developer.

WPF on the desktop just gives developers wanting to unify the web and
desktop experience an option. Over time it will probably replace
WinForms, but I could see WinForms sticking around for a few
generations.

JDeats--you'll be interested by the below extract on the benefits of
WPF over WinForms. But the problem I have is that I just fired up
VS2008 and wrote a 'hello world' program, and found to my chagrin:
WPF has no "lightning bolt" to pick from an array of Event Handlers
(*noted by others as well, see below*), rather, you simply double
click on a control and a 'default' event handler arises (such as
double clicking on a button will give a "_Click" handler). This is
because the controls in WPF do not have as rich a set of EventHandlers
as in WinForms. For example, with a label, you cannot use it for
debugging by writing "label1.Text = myObject.ToString()" for example--
the .Text extension method does not exist for label. A minor point,
but I only spent five minutes in WPF and have concluded it's still
beta-ware--apparently a better programming interface called "Blend"
was released about three months ago by MSFT, in an attempt to overcome
this, but I think the 'steep learning curve' associated with WPF is
because of the rewrite of the library, which is not like WinForms or
MFC. Also you need to have a dual monitor IMO to program WPF--they
back more information than can fit in one screen. Of course dual
monitors are always a good idea in programming.

*See here: http://forums.msdn.microsoft.com/en-US/wpf/thread/c08b83dd-e9b7-49b5-86d2-291ba9ed04ab/

RL

From the excellent book: C#3.0 in a Nutshell by Albahari et al.
(O’Reilly), p. 166.

Windows Presentation Foundation (WPF)

WPF is a rich client technology new to Framework 3.0. Framework 3.0
comes preinstalled on Windows Vista-and is available as a separate
download for Windows XP SP2.

The benefits of WPF are as follows:
It supports sophisticated graphics, such as arbitrary transformations,
3D rendering, and true transparency.
Its primary measurement unit is not pixel-based, so applications
display correctly at any DPI (dots per inch).
It has extensive dynamic layout support, which means you can localize
an application without danger of elements overlapping.
Rendering uses DirectX and is fast, taking good advantage of graphics
hardware acceleration.
User interfaces can be described declaratively in XAML files that can
be maintained independently of the "code-behind" files-this helps to
separate appearance from functionality.

Here are its limitations:

The technology is less mature than Windows Forms or ASP.NET. Its size
and complexity make for a steep learning curve.
Your clients must run Windows Vista-or Windows XP with Framework 3.0
or later.

The types for writing WPF applications are in the System. Windows
namespace and all subnamespaces except for System. Windows . Forms.

Windows Forms

Windows Forms is a rich client API that-like ASP.NET-is as old as
the .NET Framework. Compared to WPF, Windows Forms is a relatively
simple technology that provides most of the features you need in
writing a typical Windows application. It also has significant
relevancy in maintaining legacy applications. It has a number of
drawbacks, though, compared to WPF:

Controls are positioned and sized in pixels, making it easy to write
applications that break on clients whose DPI settings differ from the
developer's.
The API for drawing nonstandard controls is GDI+, which, although
reasonably flexible, is slow in rendering large areas (and without
double buffering, flickers horribly).
• Controls lack true transparency.
Dynamic layout is difficult to get right reliably.
The last point is an excellent reason to favor WPF over Windows Forms-
even if you're writing a business application that needs just a user
interface and not a "user experience." The layout elements in WPF,
such as Grid, make it easy to assemble labels and text boxes such that
they always align-even after language changing localization—even
without messy logic and without any flickering.

Further points made on the next page: WPF is faster, since GDI+
hardware accelerators never became popular with manufacturers, who
chose DirectX. Thus GDI+ is actually “considerably slower” than GDI,
let alone WPF.

On positive side, Windows Forms relatively simple to learn and has
third-party support.


RL

 

[raylopez99]

I agree with this. However, once the learning curve tax is paid, it gets
easier.

The "tax" you are paying is essentially being a beta tester for
Microsoft. Blend (TM), the User Interface for programming in WPF, was
released a few months ago, and why is that? Because the UI for WPF
sucks. See for example this thread:
http://forums.msdn.microsoft.com/en-US/wpf/thread/c08b83dd-e9b7-49b5-86d2-291ba9ed04ab/
"Where is the event handler in VS2008 RTM for WPF?" (answer: in early
editions of WPF it did not exist, and even now a very primitive event
handler wizard exists that has 10% of the functionality of WinForms).

Naïve is not the right word here at all. This model is separation is a
proven and valid approach in the web world. There's absolutely no reason why
it won't gain traction in the windows world given that the line between web
and windows is not even visible anymore, let alone blurred.

No, XAML is essentially a step backwards from binary files. Why?
Because XML is essentially a legal strategy adopted by MSFT to avoid
charges it is monopolizing. By adopting XML, they were able to argue
in court that their formats for Word, Office, Excel, etc are "open".
Same with XML. Do you really think XML serialization is easier than
binary serialization? Experts don't.

Sure XML based formats are easier for humans to read, if you like
reading XML-format. And in theory (but not in practice) XML
serialization is loose coupled, meaning it will not break between
versions (in theory, but not in practice). Look at any comparison
(such as p. 499 of Albahari's book C# 3.0 Nutshell) between binary
serialization and the others (data contract, used in WPF, and XML,
IXML). You'll see binary serialization wins on all fronts except
"interoperable messaging" and "version tolerance" (barely losing in
this last category). And "interoperable messaging" is essentially
used for web services, which you can handle with a suitable adapter--
no need to write your whole code with 'interoperability' in mind.

As for wedding graphic artists with programmers, that idea is so
ludicrous that it's laughable.

Hope I cleared up your misunderstandings.

RL

 

[Alun Harford]

The "tax" you are paying is essentially being a beta tester for
Microsoft. Blend (TM), the User Interface for programming in WPF,

Blend is not "the User Interface for Programming in WPF". It is a tool
to allow designers to produce XAML that can easily be ported into a WPF
project. Since most projects don't have UI designers, the crappiness of
Blend isn't an issue - most people will use Visual Studio.

was
released a few months ago, and why is that? Because the UI for WPF
sucks. See for example this thread:
http://forums.msdn.microsoft.com/en-US/wpf/thread/c08b83dd-e9b7-49b5-86d2-291ba9ed04ab/
"Where is the event handler in VS2008 RTM for WPF?" (answer: in early
editions of WPF it did not exist, and even now a very primitive event
handler wizard exists that has 10% of the functionality of WinForms).

Generally speaking, you should use routed commands rather than events in
WPF.

No, XAML is essentially a step backwards from binary files. Why?
Because XML is essentially a legal strategy adopted by MSFT to avoid
charges it is monopolizing. By adopting XML, they were able to argue
in court that their formats for Word, Office, Excel, etc are "open".

This isn't an issue here, since Microsoft cannot reasonably be accused
of having a monopoly on programming languages.

Same with XML. Do you really think XML serialization is easier than
binary serialization? Experts don't.

Sure XML based formats are easier for humans to read, if you like
reading XML-format.

And write! XAML is a declarative programming languages. You're supposed
to write it and let the compiler read it.


Alun Harford

 

[Alun Harford]

JDeats--you'll be interested by the below extract on the benefits of
WPF over WinForms. But the problem I have is that I just fired up
VS2008 and wrote a 'hello world' program, and found to my chagrin:
WPF has no "lightning bolt" to pick from an array of Event Handlers
(*noted by others as well, see below*), rather, you simply double
click on a control and a 'default' event handler arises (such as
double clicking on a button will give a "_Click" handler). This is
because the controls in WPF do not have as rich a set of EventHandlers
as in WinForms.

Generally, you only use events when writing custom controls in WPF (and
because you can retemplate controls, this is very rare).
When writing Xaml (for example, to determine what to do when the user
clicks a button) you should use commands.

For example, with a label, you cannot use it for
debugging by writing "label1.Text = myObject.ToString()" for example--
the .Text extension method does not exist for label.

The property you're looking for is "Content".

A minor point,
but I only spent five minutes in WPF and have concluded it's still
beta-ware--apparently a better programming interface called "Blend"
was released about three months ago by MSFT

This is not what Blend does. Blend is not a programmer's interface -
it's an interface that allows designers to easily produce Xaml (which
can then be easily turned into code by a developer). Blend is useful for
producing icons, company logos, etc. You then get a block of Xaml out
and you can use it in your code.

, in an attempt to overcome
this, but I think the 'steep learning curve' associated with WPF is
because of the rewrite of the library, which is not like WinForms or
MFC.

I think that's the major issue here. When I learnt WPF, it took some
time to figure out that I had to disregard everything I knew from
WinForms. It doesn't help that Microsoft wasn't brave enough to drop
support for user controls from the VS designer.

However, as somebody who has used both WinForms and WPF in commercial
enterprise applications, I know I would never choose WinForms over WPF
these days (unless, perhaps, I was supporting Win2000 or it was a really
small project and the other developers were not good enough to learn WPF
quickly).

Alun Harford

 

[raylopez99]

I think that's the major issue here. When I learnt WPF, it took some
time to figure out that I had to disregard everything I knew from
WinForms. It doesn't help that Microsoft wasn't brave enough to drop
support for user controls from the VS designer.

However, as somebody who has used both WinForms and WPF in commercial
enterprise applications, I know I would never choose WinForms over WPF
these days (unless, perhaps, I was supporting Win2000 or it was a really
small project and the other developers were not good enough to learn WPF
quickly).

Alun Harford

Well you are intriguing Alun Harford, and I was inspired to buy a book
by Chris Sells (a fairly decent author, I have another of his books)
on WPF. I am curious how WPF does away with event handlers.

I take it you don't think the programming interface (the Wizard if you
will) is counterintutitive, as came across at first blush to me
(albeit with only five minutes of studying it).

And your comments about Xaml are interesting. I think one problem
with WinForms for me is that generating the graphics, which generally
do not have 'cool' properties like shadowing, blending of colors, etc
(of course you can buy a third party library to do this) makes the
graphics look somewhat unprofessional in WinForms, unless you invest a
lot of time into graphic arts. We'll see if Xaml based graphics are
better. Also, as pointed out in this thread, the dpi /client
coordinates / world coordinates/ screen coordinates transformation are
a bit of a problem in WinForms (I've had to write my own library
routines to make the screen look proportional, I'm sure even more
experienced programmers have done the same thing), whereas in theory
WPF does away with this, as it does not use pixels to measure
distances (how it measures distances is beyond me at the moment, but
I'll find out; perhaps everything is mapped to a universal coordinate
space assumed to be shared by every Vista user).

RL

 

[not_a_commie]

However, as somebody who has used both WinForms and WPF in commercial

enterprise applications, I know I would never choose WinForms over WPF
these days (unless, perhaps, I was supporting Win2000 or it was a really
small project and the other developers were not good enough to learn WPF
quickly).

Amen, brother. Once you know WPF you can see how truly "naive" the
WinForms API is. Somebody above mentioned the idea that the WinForms
API could be changed to use WPF on back end. I think that's a
plausible idea. I quite like it actually. It would be a large project
but quite easy I believe. Maybe someday when I'm bored...

 

[not_a_commie]

So on this idea of creating a WinForms API that ran on top of WPF --
how much would you pay for that library? $20? $50? I promise it
wouldn't flicker on Vista and the NumericUpDown control would work
correctly ;-). Seriously, people complain about the flicker in
WinForms and the slowness of GDI+ all the time. Another thing I hate
is the exceptions that GDI+ throws. If those ran on top of WPF we
could fix most of the big WinForms issues. We wouldn't have to hide
the methods of the underlying WPF classes -- it could be a nice way
for people to transition over to WPF.

 

[Alun Harford]

Well you are intriguing Alun Harford, and I was inspired to buy a book
by Chris Sells (a fairly decent author, I have another of his books)
on WPF. I am curious how WPF does away with event handlers.

WPF has a command system that incorporates the action, whether the
control is enabled and the content of controls. Describing them in
detail relies on an understanding of the WPF logical tree, so I'll leave
that to your book

I take it you don't think the programming interface (the Wizard if you
will) is counterintutitive, as came across at first blush to me
(albeit with only five minutes of studying it).

I think the Visual Studio designer is counterintuitive, but for other
reasons...
It encourages you to make user controls, when you should make data
templates. I suspect this was a commercial decision as totally changing
the programming model harms adoption. Unfortunately, user controls make
little sense in the WPF model. I personally fell into this trap and
produced some really horrible code as a result - I've still not got all
of it out of my codebase.

And your comments about Xaml are interesting. I think one problem
with WinForms for me is that generating the graphics, which generally
do not have 'cool' properties like shadowing, blending of colors, etc
(of course you can buy a third party library to do this) makes the
graphics look somewhat unprofessional in WinForms, unless you invest a
lot of time into graphic arts. We'll see if Xaml based graphics are
better.

If you're creating visuals, WPF is hugely better than WinForms, but the
artistic element of the task is still not trivial.

Also, as pointed out in this thread, the dpi /client
coordinates / world coordinates/ screen coordinates transformation are
a bit of a problem in WinForms (I've had to write my own library
routines to make the screen look proportional, I'm sure even more
experienced programmers have done the same thing), whereas in theory
WPF does away with this, as it does not use pixels to measure
distances (how it measures distances is beyond me at the moment, but
I'll find out; perhaps everything is mapped to a universal coordinate
space assumed to be shared by every Vista user).

Unfortunately, it uses 'pixels', but totally changes the meaning of the
term (they should have called them something else). WPF pixels don't map
directly to device pixels and it's perfectly reasonable to (for example)
create a line 0.4 pixels thick. Exactly how it works is very complex,
particularly when you consider SnapToPixels and how it all interacts
with graphics drivers, graphics cards, bitmap effects, etc.

I still don't completely understand exactly how it all works (I just
push in the numbers, think carefully about anti-aliasing effects, and it
usually comes out looking pretty) - it would be really good if somebody
wrote a book on the topic.

Alun Harford

 

[Alun Harford]

So on this idea of creating a WinForms API that ran on top of WPF --
how much would you pay for that library? $20? $50? I promise it
wouldn't flicker on Vista and the NumericUpDown control would work
correctly ;-). Seriously, people complain about the flicker in
WinForms and the slowness of GDI+ all the time. Another thing I hate
is the exceptions that GDI+ throws. If those ran on top of WPF we
could fix most of the big WinForms issues. We wouldn't have to hide
the methods of the underlying WPF classes -- it could be a nice way
for people to transition over to WPF.

I think it would be intellectually interesting, but I wouldn't buy it.

If I had to use WinForms, it would be because I had to deploy to a
system I couldn't use WPF on (pre-XPSP2).

Alun Harford