I’ve been beating my head against the wall with a small problem and after lots of trial and error, and some searching around, I found the answer – and it was NOT obvious !

The problem space was simple and common:

I have placed a lot of my styles, data templates, and converters into separate XAML files (ResourceDictionaries), with the idea of just declaring them in the App.Xaml since I’m pretty much using these all over the application.  I started out declaring things in my App.Xaml like this:

<Application.Resources>
    <controls:BooleanToVisibilityConverter x:Key="booleanToVisibilityConverter" />
    <refractionConverter:ReverseBooleanToVisibilityConverter x:Key="reverseBooleanToVisibilityConverter" />
    <refractionConverter:PercentageConverter x:Key="percentageConverter" />
    <ResourceDictionary>
        <ResourceDictionary.MergedDictionaries>
            <ResourceDictionary>
            </ResourceDictionary>
            <ResourceDictionary Source="Resources/SharedResources.xaml" />
            <ResourceDictionary Source="Resources/MdiTemplates.xaml" />
        </ResourceDictionary.MergedDictionaries>
    </ResourceDictionary>
</Application.Resources>

Looks simple enough right?  Wrong.

The second I moved the converters from the individual User Controls to the App.Xaml, styles that are declared in the SharedResources.xaml file became unreachable.  In my debugging efforts, I tapped into the Application_Startup event to examine the resources that WPF was loading.  I noticed that the value of this.Resources.Count was 4, but the value of this.Resources.MergedDictionaries.Count was 0. 

So I continued digging and here’s what I found out:

Once you commit to using MergedDictionaries in your App.Xaml, you must use them for everything.  I moved the three converters inside the MergedDictionaries section and tested the debugging again.  This time, this.Resources.Count was set to 0, and this.Resources.MergedDictionaries.Count was set to 3.  This told me the resources I listed as MergedDictionaries were now loading.  The key indicator that things were better is that my styles now worked.

Here’s the code:

<Application.Resources>
    <ResourceDictionary>
        <ResourceDictionary.MergedDictionaries>
            <ResourceDictionary>
                <controls:BooleanToVisibilityConverter x:Key="booleanToVisibilityConverter" />
                <refractionConverter:ReverseBooleanToVisibilityConverter x:Key="reverseBooleanToVisibilityConverter" />
                <refractionConverter:PercentageConverter x:Key="percentageConverter" />
            </ResourceDictionary>
            <ResourceDictionary Source="Resources/SharedResources.xaml" />
            <ResourceDictionary Source="Resources/MdiTemplates.xaml" />
        </ResourceDictionary.MergedDictionaries>
    </ResourceDictionary>
</Application.Resources>

I hope this helps since believe it or not, though there’s a lot of code samples out there, much of it is unclear and flat out wrong.

Until next time…

I’ll be doing a user group triple play this month starting on Tuesday, Dec. 14 at the Northern New Jersey .NET User Group.  On Wednesday, the 15th, I’ll be at the Philly .NET User Group, and on Thursday the 16th, I’ll be visiting the New York City .NET User Group.

The topic will be the same across all three groups, though the name seems to be different in each one.  I guess the common title would be, “Programming With MVVM”.  Here’s the session description:

WPF overwhelmed us with the most powerful data binding ever released in a development platform. It seemed there was so much to learn in order to use it, but it really isn't that complicated. However, to use it to its full potential, you really do need to introduce the Model-View-ViewModel pattern. The ideas and goal around this pattern seem to vary from person to person, but the one thing that they all share is that it provides a point of binding for XAML pages. In this session, I'll show you what MVVM is and how to use it and what to put in it, in order to get maximum potential out of XAML binding. I'll even show you how to get a small MVVM Framework going for sharing across all your applications.

I’m going to be a little different on this posting and talk about an actual pay-product that is totally worth your while to look at.  The product I’m talking about is called DocumentX 2010 and it’s by a company called Innovasys.

I’ve been dealing with Innovasys for a long time now.  Back when I first started developing CodeBreeze, I was on the hunt for a good help authoring system in order write a quality help system for my own applications and I came across the original Document X.  First, let me tell you what Document X does.  Put simply, it lets you develop MSDN-style documentation for your APIs and object models.  It comes with its own full-feature IDE, but also fully integrates with Visual Studio and also imports <summary>-style documentation directly from your code.  Document X has the concept of content files that let you define all the documentation for a specific assembly, then by creating a project file, you can important as many content files as you want.  The end-result is a help file that can incorporate multiple assemblies.  Innovasys also makes a sister product called Help Studio, which is used to author complete help systems for your applications.   With Help Studio you can create any number of topics, glossaries, and custom tables-of-content.  Into a Help Studio project, you can important a Document X project, giving you a complete single help file for your application that contains all your user-help, the way you designed it, as well as the object-model documentation in MSDN format.

The reason I felt it important to share my experience with you is because it was a unique one.  Using the Document X product, along with its sister application, Help Studio, I was inspired to take certain approaches during the design and development of CodeBreeze.  As I used the product suite, I noticed that every part of the application can be customized, including the templates for the help being generated.  The usage of context menus, short-cuts, tabbed-MDI, and other UX details was extensive and I became very impressed with the way the suite was built.  The guys at Innovasys seem to go out of their way to provide the best and most intuitive user experience possible.  Normally, the task of creating documentation can be quite tedious, but the best compliment I can give Innovasys is that it’s a task that I actually enjoy.

The more I used the Document X and Help Studio product suite, the more I found myself changing things in CodeBreeze to provide a better and better user experience.  It became quite frustrating, but in a good way .  A couple of years later, at the Los Angeles PDC, I got the opportunity to meet the Innovasys team after exchanging emails when them for a while and they were as pleasant I person as they were on-line. 

Document X is on its 2010 release and HelpStudio is about to be released as the 2011 version, both are written in WPF, and based on all the conversations I’ve had with Innovasys, the applications have a solid architecture and do their predecessors proud in all the usual attention to detail.

I’ve had the opportunity to dialog quite a bit with Innovasys and it’s no surprise their products are built so well.  It such a treat getting into real geeky conversations with these guys.  Recently, our conversations have been about WPF, MVVM, abstractions, templates, and other great technologies used in the latest versions of their products.  The new versions of Document X and Help Studio are built entirely in WPF and I gotta say that once again, their proving an inspiration in the next version of CodeBreeze, to be released sometime next year.

Be sure to check out their apps at www.innovasys.com, where you can download a free trial for all their products.

Keep up the great work guys.

Until next time…

Oh boy, this one just drove me insane for over two hours.

First of all, I have a ViewModel that is bound to a user control on a “start page” of my application which is designed to show a Recent Files list.  The displaying of this list worked just fine.  The ViewModel encapsulates a command member whose execution method is within the ViewModel class itself.

The command is declared and initialized in my view model like this:

public override void InitializeViewModel()
{
    FileSelectedCommand = new DelegateCommand<Uri>(FileSelectedCommand_Execute);
    base.InitializeViewModel();
}

public DelegateCommand<Uri> FileSelectedCommand { get; protected set; }

The command’s execution method looks like this, but what it’s doing is not what’s important here.

void FileSelectedCommand_Execute(Uri arg)
{
    if (arg != null)
    {
        _RecentDocManager.NotifyDocumentOpened(arg);
        OnFileSelected(new FileLocationEventArgs(arg));
    }
}

What is important is the argument that it’s set up to receive.  Notice that in this case, it’s a URI, which is the exact type to which the CommandParameter argument in my view is bound:

<src:StartPageViewBase.Resources>
    <shared:CommandReference x:Key="fileSelectedCommand" Command="{Binding Path=FileSelectedCommand}" />
    <ResourceDictionary x:Key="dict1">
        <ResourceDictionary.MergedDictionaries>
            <ResourceDictionary Source="/Views/SharedResources.xaml" />
        </ResourceDictionary.MergedDictionaries>
    </ResourceDictionary>
</src:StartPageViewBase.Resources>
<Grid>
    <ItemsControl ItemsSource="{Binding Path=Documents}" DataContext="{Binding}" Grid.IsSharedSizeScope="True" Margin="5,5,5,5">
        <ItemsControl.ItemTemplate>
            <DataTemplate>
                <Button Style="{DynamicResource {x:Static ribbon:RibbonStyles.ButtonKey}}" HorizontalContentAlignment="Left"
                        Command="{StaticResource fileSelectedCommand}" CommandParameter="{Binding Path=Location}">
                    <Grid>
                        <Grid.ColumnDefinitions>
                            <ColumnDefinition Width="Auto" SharedSizeGroup="Name" />
                            <ColumnDefinition Width="*" />
                        </Grid.ColumnDefinitions>
                        <TextBlock Grid.Column="0" Text="{Binding Path=Name}" Margin="0,0,3,0" />
                        <TextBlock Grid.Column="1" Text="{Binding Path=Location}" ToolTip="{Binding Path=Location}" Margin="0,0,3,0" />
                    </Grid>
                </Button>
            </DataTemplate>
        </ItemsControl.ItemTemplate>
    </ItemsControl>
</Grid>

The problem that drove me crazy was the fact that originally my command was declared with a string in the generic type, and in the case of a delegate-command (or a relay-command as it is otherwise known), the generic type defines the type that the potential argument will be.  The CommandParameter argument shown above is bound to a data context member called Location, and this member is a URI, not a string.

The simple mistake of having declared FileSelectedCommand as DelegateCommand<string>, completely disbled the button to which the command is bound.

Uhhhhhhg!

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

On another topic, I haven’t done a very good job regularly posting the “This Week In Code” series.  I’m not going to stop doing it, and I promise to try to get back to making it weekly as in the first four, but I’ve been traveling a lot lately and could never guarantee where I’m going to be from one week to the next.

Until next time…

My good buddy, Wally McClure was just featured in an article for “Application Development Trends” on iPhone development using Mono-Touch.  Wally has been speaking on this around the country, and I was actually an audience member in CodeStock this year.  I gotta say, I found the topic informative an intriguing, since I fall into the very category that he targets, .NET devs with iPhones.

It’s definitely a topic worth talking about since it brings together to really great platforms.  The article is not a how-to, it’s an interview conducted by Michael Desmond (isn’t that one of the former Monkees?), but it’s a nice read.

Check out the article at http://adtmag.com/articles/2010/09/29/monotouch-qa-with-wallace-mcclure.aspx.