.NET & Funky Fresh

Syndication

News

  • <script type="text/javascript" src="http://ws.amazon.com/widgets/q?ServiceVersion=20070822&amp;MarketPlace=US&amp;ID=V20070822/US/bluspiconinc-20/8001/8b68bf4b-6724-40e7-99a5-a6decf6d8648"> </script>
Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Response to 'WPF, What am I missing...Am I slow?'

Derik Whittaker, a very experienced WinForms developer, has written a post about his initial frustrations with WPF since its recent release.  He brings up some very valid points and asks why he should bother with it anymore.  I would like to address some of his questions and concerns and hopefully show others with a similar experience that taking a deeper look at WPF is a very good idea.

Derik begins his time with WPF where most people would: the VS designer.  Unfortunately, this is the wrong place to begin.  While .NET 3.0 has been released, the extensions to VS that support the API are still betas.  In fact the real stuff isn’t coming until Orcas.  On top of that, the worst plugin is the Cider designer for WPF.  In the last 16 months that I have been working with WPF I have used the VS designer probably 10 minutes max; enough to see that it was completely worthless.  If you want a drag and drop designer for WPF, use Expression or Aurora.  I prefer to work straight with Xaml.  I hardly use the VS designer for ASP.NET apps either; I mostly work straight with html for the same reason – I’m fast at it and the markup I produce is precise.  I’m sure the designer will support basic event wiring like everyone expects when it is finished, in the mean time here’s the Xaml for creating a button and wiring its click handler (you can, of course, do this entirely in code as well):

<Button Click=”MyClickHandler”>Some Content Here</Button>

And the c#:

protected virtual void MyClickHandler(object sender, RoutedEventArgs e) {  }

Looking at this code, I can see at least two great things about WPF already that everyone should know and take advantage of:

1.       I can put ANYTHING inside the button tags.  I just put text in this case.  But I could have put 2d graphics, 3d animation or an entire web page if I wanted.  The flexibility is tremendous.  That’s for the button’s content.  Using styles and control templates I can make the button itself look like almost anything I want.  Some of this is actually impossible with WinForms, the rest is difficult, time consuming and tedious.  Who out there actually liked using GDI+ to draw a custom button?  Most people gave up on that and bought something like Infragistics and then spent many frustrating hours muddling through their APIs.  Even with a 3rd party control vendor, you can’t even get close to the power of WPF.  Not by a long shot.

2.       Did you notice something different about the button’s click handler?  The event args is of type RoutedEventArgs.  In general, throughout WPF you will find events that pass more specific and useful information than in WinForms.  This often makes the handler’s code more succinct.  More importantly than this is the “routed” aspect of the args.  There is a new event mechanism in WPF, called Routed Events that provides awesome support for event bubbling and tunneling.  For example, let’s say I had a panel with a bunch of  UIElements in it and I wanted the panel to handle any click from any button in the panel:

 

<StackPanel Button.Click=”MyHandler”>

            <Button />

<Button />

<Button />

</StackPanel>

 

How do you know which button was clicked?  The RoutedEventArgs has a property called OriginalSource that tells you.  That’s cool and it simplifies a very common UI scenario.

 

Derik also mentioned that the IDE kept trying to tell him that his method was invalid.  This is just another symptom of immature VS extensions.  You have to compile once in order for the intellisense to work in C#.  I imagine this will be fixed in Orcas.  To sum up this first point: the problem isn’t with WPF, it’s with VS and the current betas of the extensions.  Work with Xaml for a little bit and you probably won’t need, or for that matter, want a designer.

 

This brings me to Derik’s next question.  What purpose does Xaml serve?   What’s wrong with the old way of component initialization? The answer to this could be quite long, but I will try and be brief.  There are two good reasons for Xaml right from the get go.  The first is that Xaml is easy to read and understand, much easier than the generated code from the WinForms designer.  Xaml was intended to be human readable and human writable.  It’s quite easy to look at a piece of Xaml and understand exactly what the UI looks like and does, much easier than looking at the type of C# code that it takes to accomplish the same thing.  Xaml markup was designed to be modified by people, unlike the generated WinForms code, which you dare not touch if you value your work.  This brings me to the second point:  Xaml (being xml) is much easier to parse than C# code.  This means that better design time environments can be built on top of it than C# code.  Synchronizing C# code with a designer is very difficult; synchronizing Xml is considerably easier.  Expression and Aurora are two great examples of the types of designers that can be built to generate Xaml.

 

One neat thing about Xaml is that you can use it to instantiate a UI at runtime.  In other words, you could store a UI, style, set of control templates, etc in a database and at runtime instantiate that and display it.  Using this type of strategy in combination with WPF’s new databinding and command capabilities, you can build a very powerful MVC architecture.  Speaking of MVC, all controls in WPF are designed with a form of MVC.  You can see this when using control templates.  This is what allows a control’s look to be entirely separated from its function.  In short, with Xaml, composing UIs just got a strong dose of steroids.

 

When pondering the uses of Xaml Derik says:

 

The only solid reason I can see for XAML is so that some day in the far, far distant future, M.S. makes it so that a WinForm app can run like a browser app and vis versa...  Is this the intent???

 

Well, I’m not sure if this was the original intent or not, but it’s not the far, far distant future actually.  Today you can deploy a WPF application as an .xbap and run it in a browser on your pc.  Additionally, you can run loose Xaml files in your browser.  Here’s an example that displays loose Xaml and uses it to navigate to an XBAP.  (It’s not very often that you get to see interactive 3d data visualization in your browser . . . not often yet.)  Also, MS is working on a sister technology called WPF/e that is a cross-platform, cross-browser subset of WPF and the .NET framework.  They were hoping to release some time in 2007.  This will enable developers to use WPF and C# to author applications for Linux and Mac.  Even if you are not writing cross-platform applications, consider the simplicity of distributing and updating and XBAP; just copy the files to the server!

 

Derik’s last issue with WPF is the number of out of the box UI controls.  This is a pretty valid point.  Due to deadlines, the WPF team was not able to include several controls that WinForms developers have come to expect.  Two of the controls Derik mentions, calendar control and up down control, are not available as part of WPF, however a WPF team member has built them along with several other cool controls and made it available for download here.  The other two controls that Derik mentions, ListView and LinkLabel, are actually available in WPF.  The ListView goes by the same name and is quite a bit more powerful than the WinForms ListView.  (Here's a good resource.)  You’ll need to use Hyperlink controls inside of a TextBlock to accomplish the LinkLabel’s functionality.  (As a side note, Derik, your toolbox may be missing some items; Listview should be there.)  In defense of the any other controls which may be missing from WPF, let me say this:  It is much easier to build custom controls in WPF than in WinForms.  Although, your need to do so will be much rarer due to the power of control templates and data templates.  For a brief intro to data templates check out the list box in my recent blog post.  You can download the source there as well.

In conclusion, I think Derik had some excellent questions and concerns.  I hope I was able to clarify several points of confusion and convince any frustrated readers that taking a deeper look at WPF is worthwhile.  You may not be in a position to start building projects with WPF right now, but I hope you will consider it for future work and if anyone has questions regarding the functionality of WPF or any problems they are encountering, please feel free to contact me; I would enjoy helping you find a solution.

Posted 11-13-2006 12:17 PM by Rob Eisenberg
Filed under: , ,

[Advertisement]

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)