Paul Stovell says…

One difference between XAML in a C# project and VB.NET projects is in specifying the x:Class of your XAML root element. For example, in a C# Window XAML file:

<Window
    x:Class="BigBank.UI.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300"
    >
    <Grid>

    </Grid>
</Window>

By contrast, the VB.NET version must leave out the namespace:

<Window
    x:Class="Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300"
    >
    <Grid>

    </Grid>
</Window>

If you forget to make these changes, a typical error message you might encounter is "Name ‘InitializeComponent’ is not declared", or similar. This occurs because the generated VB.NET file to load the XAML is placed into a namespace different to the one of your code-behind, and thus the code behind can’t find it’s partial class which declares the method.

Where this becomes inconsistent is when you include other namespaces in your project, whereby you do need to use the fully qualified namespace:

<Window
    x:Class="Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:me="clr-namespace:BigBank.UI.Controls"
    Title="Window1" Height="300" Width="300"
    >
    <Grid>

    </Grid>
</Window>

This issue typically comes up when converting VB.NET XAML files to C# projects or vice-versa. I’m used to the VB.NET language being woefully inconsistent, but now that inconsistency is leaking into my XAML?

Filed under: WPF | 5 Comments »

Why are so many technical decisions made by non-technical people? Because technical people don’t have the patience to read through the information coming out of the vendors

Vendors should provide a technical-people-only portal of their websites, similar in principal to the Simple Wikipedia site. A site which would cut through all of the Enterprise-induced buzzword soup, and get right to the technical details. Take this page on Performance Point:

Microsoft Performance Management allows customers to monitor, analyze, and plan their business as well as drive alignment, accountability, and actionable insight across the entire organization.

All I wanted to know is whether Performance Point would make a good tool to analyze the stats on my blog. I’ve read the whole page, and I’m still not any closer to knowing. That said, I can’t think of how I would "drive actionable insight" over my blog, so maybe I have my answer.

Thankfully, they have a "Was this information helpful" box at the bottom of the page. I hope someone is "driving actionable insight" over the feedback from their page

Filed under: Commentary | 4 Comments »

In my WPF and XAML Coding Guidelines page (which I’ll be updating soon) I discussed a little rule I follow to keep my markup looking nice. Daniel Crenna has provided a nice VS addin that reformats XAML by lining up the attributes. His post has a nice animation that shows what the tool does. The Ctrl+K, Ctrl+Z shortcuts are now permanently mapped to my brain

My only complaint is that the XAML is formatted according to the position of the first attribute, rather than putting the first attribute on the next line ensuring a constant indentation level. I’m sick of formatting XAML manually though, so I’m more than happy to follow his convention given it is automated.

Filed under: WPF | 3 Comments »

(This was inspired by a funny story left by Matt Hamilton)

"Where’s the Data Grid?"

When I talk to customers that are doing Windows Forms and evaluating WPF, this has to be the most common question. Their prayers will now be answered: a data grid will be included in the .NET 3.5 SP1.

Why did it take so long?

Personally, I’m glad the WPF team waited this long to ship a data grid. The Windows Forms team spent a lot of time building data grids, but they never did anything about making the rest of Windows Forms easier. Consequently, you could use the data grids, but heaven help he who wanted anything else.

The Data Grid Lifestyle

Over time we got used to it. No matter what kind of list you had, everything was a Data Grid. If our needs were really particular, we had plenty of third party data grids too. Spend any time in Windows Forms land and your brain will physically rewire itself to think in terms of data grids.

Take the Google reader UI, cleverly optimized for reading RSS feeds quickly. Who needs a Data Grid?

But an application designed with the same functionality in mind, RSS Bandit, when designed for a Windows Forms world can easily become, well, a Data Grid with Preview pane:

The Preview pane, funnily enough, is done with HTML, since Windows Forms made it so hard to do anything else but Data Grids (and not to knock RSS Bandit; it is still my favorite reader after Google Reader, and it’s still leaps and bounds ahead of the horrid Outlook 2007 feed reader).

Are Data Grids ever the best solution?

When you think about ways to visualize most data, there are actually few places where an inline editable data grid with paging and sorting and grouping really make sense. For almost every kind of data, there’s a better way to display it than a plain old grid. Data grids are the backup, solve-any-problem solution, but almost never the optimal solution. They are a great choice when you don’t really understand the application you are building or the data you are working with.

My hope is that .NET 3.5 SP1 will encourage line of business developers to try WPF, since there is a data grid, so that they can then discover the power of non-Data Grid UI’s and never actually use one

To paraphrase Chuck Jazdzewski: If you are using Data Grids in WPF, you are doing it wrong.

Filed under: WPF | 11 Comments »

One of the upcoming additions in .NET 3.5 SP1 is a StringFormat parameter you can pass along with your bindings. Sacha Barber has an example of how to use it:

<TextBlock
    Text="{Binding Path=AccountBalance, StringFormat='You have {0:c} in your bank account.'}"
    />

However, if you can’t install the service pack or you haven’t been able to upgrade to .NET 3.5, don’t fret. Here’s a snippet, albeit with a few more lines of code, to perform the same thing:

<TextBlock>
    <TextBlock.Text>
        <MultiBinding
            ConverterParameter="Hello {0} {1}, you have {2:c} in your account"
            Converter="{StaticResource StringFormatConverter}"
            >
            <Binding Path="FirstName" />
            <Binding Path="LastName" />
            <Binding Path="AccountBalance" />
        </MultiBinding>
    </TextBlock.Text>
</TextBlock>

...

class StringFormatConverter : IMultiValueConverter
{
   public object Convert(object[] values, ..., object parameter)
   {
       return string.Format(parameter.ToString(), values);
   }
}

Hooray for String.Format :) 

Filed under: WPF, Binding | 5 Comments »