On the Road to MIX ‘09

I’m writing this particular blog post while in the air on the way to Las Vegas. For the next three days, I’m going to be at the MIX ‘09 conference. For regular readers of my blogs, that means you can expect a flurry of posts. I tend to live-blog the sessions that I’m in (particularly the keynotes) as a way of note taking, if nothing more. In this way, if nothing more, it is completely different than the MVP Summit I was at a couple of weeks ago.

Actually, there are some other differences. Where the MVP Summit is as much about giving information to Microsoft as it is about receiving, MIX is all about the receiving. While I have some inkling about some of the announcements that you’ll be hearing about, I also know that they have kept some under wraps. Which means that they were even held back from the NDA sessions at the MVP Summit. So, even though I already have some blog posts ready to go, I will still need to pay attention to what’s being discussed. And I’ll pass the good stuff on to you as soon as I can.

The Patch I Didn’t Even Know I Needed

I have been working with WPF and Silverlight pretty steadily for the past 6 months or so. And thanks to Rocky Lhotka, a problem that I didn’t even realize I had has been (probably) corrected.

The problem was that occasionally Visual Studio would just go away. No warning. No error. Just disappear. It didn’t happen that often for me, but I have had awkward moments while teaching a course. Even in that situation, neither I, nor any of the students did anything but shrug, chuckle and restart. These things do happen in the world of software development. The fact that we were willing to just accept it unquestioningly is a blog post for another day.

However, while perusing my blog roll yesterday, I came across this post from Rocky. It talks about a hotfix for a problem that causes Visual Studio to just disappear. Way too coincidental. A quick download and, hopefully, I’m inoculated from this issue going forward. If you’re using WPF in Visual Studio, it’s a fix you might strongly consider.

Fixing ‘prop’ Snippet Compatibility

As you might have gathered from reading my recent post on changing generated code in VS2008, I wasn’t thrilled when Microsoft changed the behavior of the prop snippet between VS2005 and VS2008. It’s almost two years later and my fingers still want to type 'prop’ even when I know that using automatic properties is very, very unlikely to be the thing that I want to generate.

My solution to this consternation was to create a custom snippet. The XML found below can be used to create such a snippet. In this case, the snippet is named ‘propfull’ and its template creates a property complete with the backing variable. It can be loaded into Visual Studio by using the Import button found in the Tools | Code Snippet Manager dialog box. The other possible approach would be to edit the snippet that comes with VS2008, but I’m loath to make that type of change to the default. Changing behavior that others have come to expect would evil, wouldn’t it Microsoft?

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  xmlns="
http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
    <CodeSnippet Format="1.0.0">
        <Header>
            <Title>propfull</Title>
            <Shortcut>propfull</Shortcut>
            <Description>Code snippet for property implemented using a backing store</Description>
            <Author>Bruce Johnson, ObjectSharp Consulting</Author>
            <SnippetTypes>
                <SnippetType>Expansion</SnippetType>
            </SnippetTypes>
        </Header>
        <Snippet>
            <Declarations>
                <Literal>
                    <ID>type</ID>
                    <ToolTip>Property type</ToolTip>
                    <Default>int</Default>
                </Literal>
                <Literal>
                    <ID>backing</ID>
                    <ToolTip>Backing variable name</ToolTip>
                    <Default>myProperty</Default>
                </Literal>
                <Literal>
                    <ID>property</ID>
                    <ToolTip>Property name</ToolTip>
                    <Default>MyProperty</Default>
                </Literal>
            </Declarations>
            <Code Language="csharp"><![CDATA[
private $type$ $backing$;           
public $type$ $property$
{
   get { return $backing$; }
   set { $backing$ = value; }
}$end$]]>
            </Code>
        </Snippet>
    </CodeSnippet>
</CodeSnippets>

My Biggest Disappointment at the MVP Summit

I’ve just come home from spending the last three days in Redmond at the MVP Summit. For those who might not be aware, the Summit is an annual event that Microsoft hosts for Most Valuable Professionals (MVP). The MVP designation is given to people who have contributed in a positive way to the community through speaking, blogging, answering questions in forums or organizing user groups and conferences at the local level. At the Summit, the various product groups get the opportunity to demonstrate some of the futures for their products in order to solicit feedback. The chance to meet and talk with product group members is actually one of the main benefits of being an MVP to me. They are people who are passionate about the code they write and who love to hear about the good and the bad.

However, the futures that are being discussed are really that. We’re not talking about what’s going to be in VS2010. The feature list for that has been set in stone for a while and is generally well known. Instead, we’re talking about what might be coming in the next version of Visual Studio. Or Silverlight. Or ASP.NET. Or Data Programmability. These futures have not, for the most part, even been designed much less coded. So to talk with us about this, MVPs at the Summit (and, indeed, all MVPs) have to sign a non-disclosure agreement (NDA). This means that we cannot discuss with anyone outside of the MVP community what we have seen and heard until the information becomes public.

Today’s technology, combined with the outgoing personalities of MVPs makes this restriction a challenge. Normally when I’m at a conference, I’m live blogging the session that I’m in. Or I’m twittering my schedule. Can’t do that here. It gives me itchy fingers, but the NDA is taken quite seriously. Even the code names for various projects are considered NDA, a problem for the person who unthinkingly twittered one while in sessions on Monday.

So that inability to share is my biggest disappointment. Not an unexpected one (I’ve been to the Summit before and am under NDA constraints constantly), but still a source of sadness nonetheless. But let me just say that I’ve already written some blog posts that will be published once the details of the products are made public in the near future. Hopefully that little tidbit of foreshadowing won’t get the NDA police on my trail.

Clearing the Debugging Tooltip

On the scale of annoyances, this is not a huge one. But the solution is so simple, that it’s worth a quick post.

Have you ever been in the middle of debugging an application and used the hover functionality to display the current value of a variable? And expanded multiple levels to find the specific property that you’re looking for? Of course you have.

But have you ever been frustrated when the debugging view obscures a piece of code that you’re interested in? So that you have to close the debugging tooltip to see the code and then navigate through the hierarchy to get back to what you were looking for? Odds are that it has happened to you. It certainly happens to me frequently enough.

Fortunately, there is a solution. While the debugging tooltip is displayed, simply press the Ctrl key. This instantly makes the tooltip transparent. And when you release the Ctrl key, the tooltip reappears. Simple and elegant, just the way all solutions should be.

Thanks to Dave Lloyd and Brian Rasmussen for the information (same tip at different times).

Changing Generated Code in VS2008

Have you ever been dissatisfied with the code that is automatically generated by Visual Studio in response to various commands that you perform. For example, in VS2005, I got used to using the prop snippet to create properties. This snippet created a property declaration complete with a private backing variable. However, in VS2008, the prop snippet was modified to create a property declaration in the form of the automatic property declaration. That, to me, was annoying.

(Note to Microsoft: Please consider the existing snippets to be part of what you consider when looking at backwards compatibility. Create more snippets, sure. But please don’t change what the current snippets do…especially when the ‘better’ snippets are not actually better)

Or, consider the fact that, as more and more work is done in WPF, the need to ensure that business classes implement INotifyPropertyChanged grows. Adding or modifying a snippet to include the code to call PropertyChanged could be quite useful. It certainly has been for me.

Little known by most developers is the location for the snippets that Visual Studio provides. Or, what might be more interesting to intrepid developers, the snippets used by Visual Studio refactoring. All of these are found in %ProgramFiles%\Microsoft Visual Studio 9.0\VC#\Snippets\1033. The keyword snippets can be found in the Visual C# subdirectory, while the refactoring snippets can be found in the Refactoring subdirectory. Take a look at what’s there and you may be surprised how you can increase your productivity for mundane (and frequent) tasks.

“Fixing” the WPF Designer

If you use WPF on a regular basis, then I can take a good guess as the esteem in which you hold the designer. While it has it’s place, hard code WPF devs using XAML directly. It’s much each to get the result that you’re looking for quickly. The problem I’ve always had is that when you open a WPF file, even when you have disabled the design portion, there is still a significant time lag.

Thanks to Fabrice Marguerie who wrote this blog post which describes how to eliminate that annoying delay.

It’s nice to have less friction between me and my XAML. :)

Excel automatically defines column types

So to set up this problem, an application that I'm currently working on needs to process data that is stored in an Excel spreadsheet. The creation of the spreadsheet is actually performed by a scientific instrument, so my ability to control the format of the output is limited. The instrument samples liquids and determines a quantity. That quantity is placed into the spreadsheet. If the quantity in the liquid is not successfully read, then the literal "Too low" is placed into the sheet. The application opens up the spreadsheet and loads up a DataSet using the OleDb classes (OleDbConnection and OleDbDataAdapter).

This seemed like a fine setup. At least, until some of the numeric values in the spreadsheet were not being read. Or, more accurately, the values in the spreadsheet were not making it into the DataSet. Head-scratching, to say the least.

After some examination, the problem became apparent. When the values were being successfully read, the column in the DataSet had a data type of Double. When the values were not being successfully read, the column in the DataSet had a data type of String. Now the difference between success and no-success was nothing more than the contents of the spreadsheet.

Now the obvious path to follow is how the data type of the column is determine. Some research brought me to what I believe is the correct answer. The Excel driver looks at the contents of the first 8 cells. If the majority is numeric, then the column's data type is set to Double/Integer. If the majority is alphabetic, then the column becomes a string.

Of course, this knowledge didn't really help me. As I said at the outset, my ability to control the format of the spreadsheet was limited. So I needed to be able to read the numeric data even if the column was a string. And, at present, the cells containing numbers in a column marked as a string were returned as String.Empty.

The ultimate solution is to add an IMEX=1 attribute to the connection string. This attribute causes all of the data to be treated as a string, avoiding all of the cell scanning process. And, for reasons which I'm still not certain of, it also allowed the numeric data to be read in and processed. A long and tortuous route yes, but the problem was eventually solved.

Walking the WPF Control Hierarchy

I just finished teaching a Silverlight/WPF course last week. As is true in almost every course I teach, there were questions from people who are trying to use the technology in the real world. It's what I love about teaching...that I always learn something about how people use the tools they have been given.

In this particular case, the problem was relating to walking the control hierarchy in a user control. The user control contained a DataGrid and the goal was to get from a particular cell within the DataGrid back to the user control itself. The code that was written to do so looks approximately like the following.

public UserControl GetContainingUserControl(FrameworkElement element)

{

   if (element is UserControl)

      return element;

   else

      return GetContainingUserControl(element.Parent);

}

The problem with the code is that, in the case specified, the Parent becomes null before the UserControl is found. For most developers, this is a strange and unexpected turn of affairs. For most hierarchies, it seems completely reasonable to presume that every element in a hierarchy will have a non-null parent except the root of the tree. But if you read over the description of the Parent property closely, you will see that it could be null. From MSDN,

Parent may be a null reference (Nothing in Visual Basic) in cases where an object was instantiated, but is not attached to an object that eventually connects to the Silverlight RootVisual, or the application object.

Ouch. Sure it's documented, but still. Ouch.

Fortunately, there is a solution, found in an incredibly useful class named VisualTreeHelper. This class exposes a number of methods that can be used to navigate up and down the visual hierarchy in a WPF interface component. There is, for example, a GetChild method that retrieves a particular child element. As well, of particular interest for this example, there is a GetParent method that retrieves the parent of a given element. This method will not return a null parent until the top of the visual hierarchy is reached.

In other words,VisualTreeHelper.GetParent(element) can be used in place of element.Parent in the above method with the result being more in line with expectations.

Whew.

First Post of the Year and a Gift for You

Now that the holidays are over (which weren't particularly fun for me this year, due to a persistent bout with sinusitis), it's time to get back to the posting. And to start things off, let me offer any of you who might be thinking about going to DevTeach Vancouver at the beginning of June (8th to the 12th). Jean-Rene Roy, the organizer of the conference, has offered 50% off the registration cost to the first 30 people who register with the following code: DEVT50OFFVAN. Also, the registration need to be done prior to Feb 10th.

If you've never been to a DevTeach conference, you don't know what you're missing. This is easily the top .NET developer-focused conference in Canada. They get big name speakers presenting on the latest and greatest of technologies. As well, the setup for the conference is such that the speakers are much more accessible than any other conference I've been to. So not only will you be able to hear familiar luminaries, but you'll also get the ability to speak with them one-on-one. A great deal at full price, this becomes an incredible opportunity at half-price. So if you were just thinking of going, let this offer make your mind up for you.