My WPF Code Snippets

Yikes! Has it really been over a month since my last blog entry!?!

Okay, the last 6 weeks are a bit hazy and I wish I could blame my absence from the WPF Forum (and this blog) on something exciting, but honestly, it’s just been work. A number of projects all converged at once creating “the perfect storm” of work engagements. And although I love writing WPF code, I’m now hoping for a small respite from the daily deadlines. Hopefully, the next few weeks will be a little more tame and I will be able to catch up with life in the WPF community.

Whenever we go through these crunch times, I realize how much I’ve come to depend upon the code snippet support in Visual Studio 2005/2008/2010. I totally rely on my WPF code snippets… and its not just because of the time they save me writing code, but also because of the consistency they bring to my code. I can look at any WPF classes I’ve written over the past few years and immediately understand what is going on in the properties, events, and commands exposed by those classes.

If you do not yet have a good set of Visual Studio code snippets, I would encourage you to develop them. I have posted my C# WPF snippets here for anyone who is interested in perusing, adopting, or improving them.

<UPDATE>

January 4, 2008: The downloadable snippets file now contains a .vsi file that can be used to directly import these snippets into Visual Studio 2005/2008/2010. (Special thanks to the coworker who was nice enough to create the install package for me!)

</UPDATE>

(Apologies to the VB.NET WPF developers out there… I have never ported these to VB, as the time I spend writing VB code is extremely limited. But if anyone is up for a challenge and wants to port these and send them my way, I’d be happy to post the equivalent VB snippets on my site.)

<UPDATE>

September 22, 2008: I finally got around to porting these snippets to VB. See this post for the details.

</UPDATE>

I have designed these snippets to cover 98% of the usage scenarios that I encounter in a typical WPF development project. I have also designed them to enforce good coding patterns, especially around consistency and documentation.

I won’t spend a lot of time explaining how to use them (because hopefully they are self-explanatory for WPF developers). There are really only three shortcut keywords to remember:

dp (for dependency properties)

rc (for routed commands)

re (for routed events)

From there, it’s just a matter of choosing the correct snippets from the context menu. I’ve found that I can now invoke most of my snippets without even thinking about the keystrokes… my fingers just go into “auto” mode ( d – p – <tab> – <tab> – 2 – <enter> – property name – property type – … ).

Of course, I created the blasted things, so maybe I’m not a representative sample.

In addition to the framework-specific snippets, I’ve included a few other snippets in this zip that I also use quite a bit in WPF projects… “inpc” provides an implementation of the INotifyPropertyChanged interface and “op” is used to define observable properties that raise change notifications.

For Silverlight developers, note that I use these same snippets for Silverlight projects. Well really, it’s just a few key snippets… namely, ”inpc”, “op”, and “dp”. You will want to use variation 2 of the dependency property snippets (both standard and attached properties). Just remember that Silverlight uses PropertyMetadata rather than FrameworkPropertyMetadata, so hit delete when you tab to that field in the snippet.

I’m looking forward to a day when I’ll be able to do more advanced things in my snippets (custom functions, custom formatting, capitalization, custom placement for different code parts, etc). In the meantime, I hope others will find my existing snippets useful!

Love your blog, love the snippets. Just wondering if I’m doing something wrong, the routed event helper methods have more arguments than the calls to them from the generated routed events. Is this a feature or a bug?

If you’re referring to the AddHandler() and RemoveHandler() helper methods, these are actually correct. They should have 3 arguments. These helpers are only accessed by the attached routed events. There are similarly named methods (with only 2 arguments) inherited from UIElement, which are called by the non-attached routed events.

The RaiseEvent() helper, on the other hand, is accessed by both the attached and non-attached routed events.

a fellow co-worker tells me VS sucks at really powerful stuff like this and to just use PowerShell Get-ClipBoard and Set-ClipBioard. I’d rather not depend on an external tool unless I can integrate PoerShell with VS

Yes, the re(N) snippets support derived routed event classes… but not just custom ones that I create. The framework contains many such classes itself.

For example, re3 can be used if you want to expose a DragCompleted event based on the framework’s DragCompletedEventArgs (which takes 3 parameters… double, double, bool).

I stopped at 3 because I’ve never really used any framework routed arg classes that took more than 3 arguments. (Well, there are some internal ones like ScrollChangedEventArgs, but those don’t count.)

Admittedly, I tend to use the re(N) snippets more in Surface projects or in projects where I’m defining a lot of my own attached events. For the most part, you can get by with the re0 snippet, but when you need one of the others, its really nice to have it!

Yikes! Thanks Cory… that’s a really old version of my snippets. I fixed that problem a while back, but I guess I’ve been pretty delinquent in updating the site.

If you grab the version I just uploaded, you won’t see that problem anymore in the ret snippets. You’ll also get some of the improvements I’ve made over the last 6 months.

I’ve found that I typically use the helper methods (for routed events and commands) across many classes in a project, so those snippets now create a static internal class. This way they only need to be added once to a project.

There are several other changes too, but I’m too lazy to diff the files to see what they are… probably a few other bug fixes. Let me know if you find anymore bugs!

Ok, you’re probably tired of me by now. <grin> Is there a reason that the Preview or tunneling events don’t use the RaiseEvent method on the static helper class? (The regular bubbling event uses RoutedEventHelper.RaiseEvent but the tunneling event doesn’t.)

I’m not tired of you at all… Keep scrutinizing them and I’ll keep updating them!

That was actually a problem across all the RE snippets. The first parameter on the static Raise helper was supposed to be DependencyObject (so that it can be used to target both UIEs and CEs). Not sure how long that problem has been there… probably the result of some merge/global replace gone bad. I looked back at the very first version I posted, and it was correct, but in the snippets that’ve been up there for the last 6 months, it was definitely wrong.

As of February 2008, VS2008 apparently supports a feature I just learned about today called T4 templates, that are a part of the DSL and GAX/GAT toolkits. In particular, there is a command line tool called TransformText.