My MVVM article in MSDN Magazine

Finally!  After spending more than 100 hours over several months working on an article for MSDN magazine, it is now published!  The article is about using the Model-View-ViewModel (MVVM) design pattern to create WPF applications.  My ‘WPF Apps With The Model-View-ViewModel Design Pattern‘ article is in the February 2009 issue of MSDN Magazine.  I think it is by far my best, and most important, article yet.   Big thanks go to John Gossman for giving me an in-depth tech review.

Enjoy!

MVVM Video on Channel 9

My cohort in WPF crime, Karl Shifflett, recently recorded a video on Channel 9 about MVVM.  He did a great job explaining the basics of the design pattern and showing a sample MVVM app in action.  If you want to watch this 18 minute video, here’s check it out here.

My Mix 10K Submission

Microsoft is hosting a programming contest called Mix 10K.  The idea is that you can submit an application whose binary file size is no greater than ten kilobytes, and then you stand the chance to win some cool prizes.  I don’t expect to win anything, but I still had fun creating my submission: i LOVE your cursor

I know, it’s a stupid program, but I get a kick out of it. 

NCAL Goes Live on CodePlex

Over the past couple of months at work, I have been, amongst other things, developing a library that allows you to use Infragistics WPF controls in a composite application.  If you base your composite app on Microsoft’s Composite Application Library (CAL) and want to use a third party control, such as XamDockManager, you must register a “region adapter” so that it and CAL can play nicely together.  The library I’ve been working on contains region adapters for Infragistics controls.  It is called NetAdvantage for Composite Application Library (NCAL) and is now publicly available on CodePlex.

I wrote more about NCAL on my work blog, so if you want to learn more visit this page.

Make use of the x:FieldModifier attribute

When you give an element a name in XAML, either via the Name property or the x:Name attribute, what you are really doing is supplying a field name for the class into which the XAML is converted.  By default, for whatever reason, those fields are given the “internal” access modifier.  This means that any type within the assembly that contains that class is able to access those elements.  If you appreciate the idea of encapsulation, this is clearly not a good thing!

You can use a little-known attribute called x:FieldModifier to remedy the problem.  By setting x:FieldModifier to “private” the field which references that element will be a private member of the class to which the XAML belongs.  I highly recommend doing this whenever possible, since it promotes a properly designed API for your classes that have a XAML partial.

For example, consider the following XAML:

If you look in the generated file for the Window that contains this XAML, you’ll find the following two fields:

As you can see, the x:FieldModifier determines which access modifier is applied to the fields that have a name in XAML.  The modifiers do not impact the ability to bind against the fields using an ElementName binding.  Since there is no downside to doing this, there’s no reason not to do it.