Tod's Tomes

Editing Percentages in XAML Part II

2011-12-16T12:28:00.001-08:00

Very recently (OK it was yesterday), I wrote up a blog entry on how to show a percentage and edit a percentage without it throwing exceptions or changing by orders of magnitude the backing field. Specifically storing 20% and .2 in the backend (making calculations easier) but showing the user 20% for the field.

Today, I want to share something I learned from StackOverflow member Rachel in her response to my question on why StringFormat=P doesn't work like the StringFormat=C. Rachel prefers to allow editing values in their native format, and after implementing her solution I decided I also preferred this approach. Instead of writing C# code that implements IValueConverter, this approach uses a trigger and all XAML.

The downside to this approach is it isn't as general purpose as having a converter, on the plus side it results in less cluttered XAML at the control location.

The XAML which implements the trigger could go anywhere, since these percentage fields are only used on one form in my solution I just added a <UserControl.Resources> tag at the top of the form and put the relevant XAML there. I'll only show one control, but I needed to replicate this code three times one for each control, modifying the binding in each case. In the example below you can see I still bind to my CostMarkup property in both cases but when the code is being displayed it adds a StringFormat=P, when the code is being edited there is no formatting so the field changes from 20% to .2. When the user moves off the field the display reverts back to 20%. You'll also notice I incorporated my ctrlSpacingTight style.

Trigger XAML
 <UserControl.Resources>
    <Style x:Key="CostMarkupPct"
           TargetType="{x:Type TextBox}"
           BasedOn="{StaticResource ctrlSpacingTight}">
        <Setter Property="Text"
                Value="{Binding CostMarkup, StringFormat=P}" />
        <Style.Triggers>
            <Trigger Property="IsKeyboardFocused"
                     Value="True">
                <Setter Property="Text"
                        Value="{Binding CostMarkup}" />
            </Trigger>
        </Style.Triggers>
    </Style>
</UserControl.Resources>
 

Down in the control XAML I replaced the Style tag and removed both the binding and the associated StringFormat.

<TextBox  Style="{StaticResource CostMarkupPct}" />

Displaying and Editing Percentages in WPF

2011-12-15T18:33:00.001-08:00

Showing percentages isn't even worth a blog post (spoiler alert StringFormat=P) but modifying the value proved to be more work than it seems it should be. If you show a percentage in a TextBox you want code similar to the following:

<TextBox Text="{Binding CostMarkup, 
                         StringFormat=P,
                         Converter={StaticResource pctConverter}}"/>

If you have a backing value for CostMarkup of say 0.25, it will show as 25% as shown to the left. Unfortunately, if you go in and edit the value to say 30 %, first you'll get some exceptions (depending on your Debug->Exception settings) and at best you'll end up with a red box indicating a validation error and at worst you'll have accidentally changed the markup to 3,000% (well in the case of a Markup that's kind of a happy accident if you can actually sell anything). If you try this same experiment with a field formatted for money (i.e. StringFormat=C) this doesn't happen. Obviously we avoid the multiply by 100 problem since we don't store currency in a different order of magnitude than how we display it, but that $ and all those commas don't cause us a problem either. That's really slick and it's unfortunate that the percent format doesn't do the same thing. I suspect the built in currency converter is helping out behind the scenes here.

Luckily we can manually reproduce the behavior of currency by writing our converter. Writing your first converter probably seems like a lot of work but it's not that hard and once you have one in a project, it's pretty boiler plate to write additional ones. I start by creating a new Folder named Converters under my ViewModel folder. Then since I'm a big fan of small classes I create a PercentageConverter class in its own file, that implements the IValueConverter interface.

Percentage Convertor Class
 using System;
using System.Windows.Data;
 
namespace HssOrderTracker.ViewModel.Converters
{
    public class PercentageConverter : IValueConverter
    {
        public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
        {
            return value;
        }
 
        public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
        {
            string value_str = value.ToString();
            if (String.IsNullOrWhiteSpace(value_str)) return null;
 
            value_str = value_str.TrimEnd(culture.NumberFormat.PercentSymbol.ToCharArray());
           
            double result;
            if(Double.TryParse(value_str, out result))
            {
                return result/100.0;
            }
            return value;
        }
    }
}
 

Since I'm going to use percentage fields in various places in my application, I modify my SharedResources.xaml file which holds my shared resource dictionary. At the top of my resource dictionary I add

 xmlns:Converters="clr-namespace:HssOrderTracker.ViewModel.Converters"

Then I can easily add a reference for any converter I write. For the current percent converter it looks like:

<Converters:PercentageConverter x:Key="pctConverter" />

Once all this in place, the actual XAML is a piece of cake to modify. I just add a reference to the Convertor in the binding. The final XAML becomes:

XAML with convertor specified
 <TextBox Text="{Binding CostMarkup, 
                        StringFormat=P,
                        Converter={StaticResource pctConverter}}" />
 

Now when I edit the field, the % symbol can stay there and I can enter the value as a percentage, changing the 25 to a 30 and the backing field gets set to .3, the screen shows 30% and all is well.

For completeness sake, I'll mention that I modify my app.xaml file to make my resource dictionary available as shown below:

Sharing the Dictionary
<Application.Resources>
     <ResourceDictionary>
         <ResourceDictionary.MergedDictionaries>
             <ResourceDictionary Source="View\Reusable\SharedResources.xaml" />
         </ResourceDictionary.MergedDictionaries>
     </ResourceDictionary>
 
 </Application.Resources>

If you would prefer to edit your percentages in their native format (i.e. .25), use only XAML and forgo writing an IValueConverter check out my second post on this topic: Editing Percentages in XAML Part II.

Exceptional Extensions

2011-11-22T10:52:00.001-08:00

I didn't fully embrace extensions when the were introduced, I'm finding out that was a mistake. I have started a small library with extensions for the string and exception classes. I'm sure as time goes on this library will grow. One of the things I like the most is how innocuous you can make them. You put them in your own namespace and they'll never bother anyone, but they can always come to your aid when summoned.

Recently I was working with Entity Framework and got a Validation Error. Finding out how to retrieve the actual errors was not intuitive and is exactly the kind of thing I immediately forget after I write it. Then I need it again in a future project, so I either write a blog so I can remember or I go searching through Subversion. Now, when appropriate I can just add it to my extension library. Inside my Syncor.Extensions.ExceptionExtensions class I recently added the following two extension methods (the first one was inspried by this answer at StackOverflow).

Two Exception Extension Method
 public static string GetAllValidationErrors (this List<DbEntityValidationResult> eveList)
{
    StringBuilder sb = new StringBuilder();
    eveList.ForEach(eve=> sb.Append(eve.GetValidationErrors()) );
    return sb.ToString();
}
 
public static string GetValidationErrors(this DbEntityValidationResult eve)
{           
    StringBuilder sb = new StringBuilder();
    string entity_msg = String.Format("Entity of type:{0}, in state:{1}, has the following validation errors:\n",
                               eve.Entry.Entity.GetType().Name,
                               eve.Entry.State);
    sb.Append(entity_msg);
    var err_msgs = eve.ValidationErrors.ToList().Select(ve =>
        String.Format("  Property: {0}, Error: {1}\n", ve.PropertyName, ve.ErrorMessage));
    err_msgs.ToList().ForEach(msg => sb.Append(msg));
    return sb.ToString();
}
 

You could easily make this one method if you wanted. I just find it more flexible and easier to understand when broken apart. Not only will I never forget how to do it, I won't need to remember, and the code that uses this is now pretty clean:

The clean catch
 catch (DbEntityValidationException ex)
{
    string full_msg = ex.EntityValidationErrors.ToList().GetAllValidationErrors();
    RaiseError(full_msg);              
}
 

Another useful exception extension is one that chains together the immediate extension message and any messages from inner extensions. It looks like this

Chain Inner Exception Messages
 public static string ChainExceptions( this Exception source)
{
    StringBuilder sb = new StringBuilder();
 
    while (source != null)
    {
        sb.AppendFormat("{0}\n", source.Message);
        source = source.InnerException;
    }
    return sb.ToString();
}
 

The use of this extension might look like:

Using ChainExceptions
 catch (Exception ex)
{
    var msg = String.Format("An error occurred while trying to save changes back to the database.\n{0}",
               ex.ChainExceptions());
    RaiseError(msg);
}
 

Don't you just hate inconsistent hives?

2011-11-03T05:12:00.000-07:00

While trying to install some SQL Server tools recently, I found out my computer was in violation of the "Performance counter registry hive consistency check" rule. Oh no! The link next to this error sends you to a Microsoft knowledge base article that has a set of directions that made me cancel all thoughts of getting any productive work done for the rest of the day.

Luckily a geek with a blog figured out that all of this is unnecessary. I was able to follow step 2 on his blog which was to just open the registry entry for HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib and set the Disable Performance Counters entry from 1 to 0. (I'm suspecting that implementing a suggestion for optimization by JV16 caused this.) I reran the SQL installer and no more hives! Well no more inconsistent hives anyway. Back to being a worker bee.

New WPF DataGrid Rows Throw on SelectedItem Binding

2011-10-28T10:56:00.001-07:00

In my DataGrid I have the attribute for SelectedItem bound to a property on my ModelView. This works perfectly for existing data, not so much for creating a new row. I don't understand why, but the application first throws an exception about a conversion problem with MS.Internal.NamedObject, whatever that is. Then I eventually got an exception that had the magic word NewItemPlaceholder in the message. This was the key to finding the solution. In effect what I think is happening is when a new row is created, the binding to the SelectedItem is failing. I think it may be related to the order in which things are happening. The solutions boils down to telling the system to not bother doing the binding when a new row is encountered. This requires writing an IValueConverter class and having ConvertBack return DependencyProperty.UnsetValue. Rather that duplicate the fine work of Nigel Spencer, you can get all the details on doing this from his blog post Problems binding to SelectedValue with Microsoft's WPF DataGrid. Thank's Nigel, you're a sanity saver.

Crashing Visual Studio 2010 with XAML

2011-10-26T13:52:00.001-07:00

I recently found two ways to crash the Visual Studio IDE. The first (and trickier of the two) involves adding a design time DataContext for a WPF User Control. Setting the d:DesignContext strikes me as still very useful but it helps to be aware of the potential dangers. It took me the better part of half a day to track the problem down.

The first mistake I made was I added a design time DataContext to a parent user control without making sure that all the child user controls were setting a design time DataContext. This isn't actually a requirement, but I would strongly suggest you always do this, because then you'll know what's really causing the crash. In my case, multiple generations down I had a very simple control that was unhappy but I didn't know it because the UserControl wrapping that simple control wasn't using a design time DataContext.

It Pays to Data Bind to the EXACT Matching Type

I was using the IntegerUpDown control from the Extended WPF Toolkit. It's a very useful control but it appears to be a bit persnickety when it comes to using the d:DesignContext. Keep in mind my XAML and code worked perfectly when running, it was just when Visual Studio went to parse the XAML that I had problems. It boiled down to the data binding on the Value property on the IntegerUpDown control. It expects to be bound to an int? (a nullable int) and I was binding it to a property of type int. You aren't going to get any compiler errors or warnings when you do this, or even any hints from ReSharper in the XAML code. Everything will look and work fine, until you add a design time DataContext. I suspect that when running I didn't have a problem because the Property was never null, but at design time it was.

Recursion Crash

If you're looking for another way to crash Visual Studio (aren't we all), Try referencing a view inside of itself. In my QuoteView.xaml I meant to write:

 <Quote:QuoteHeaderView Grid.Row="0" DataContext="{Binding QuoteHeaderVm}"/>
 

However, instead I wrote <Quote:QuoteView … /> which crashes surprisingly fast considering I have a lot of RAM, but maybe Visual Studio was able to short circuit running out of stack and just gave up and went home early.

The only reason I mention this bone-headed mistake is because prior to WPF I don't think I could ever do anything in my code to crash Visual Studio. That is no longer true and it's worthwhile to be aware of the price of progress.

Reusable WPF

2011-10-25T05:39:00.000-07:00

One of the immediate benefits I saw in moving to WPF was the ability to design a small (or large) user control and reuse it, both multiple times in the same application and in some cases across multiple applications. I have now done both, and even though I'm a relative newcomer to WPF, I feel there are a few simple techniques worth documenting that make the process of reusing components easier and cleaner.

Who's Got the DataContext

The biggest hurdle for me was binding to the proper data context for the control. Even in the same application there is no guarantee that a user control will be nested in the same chain. Obviously across applications you can't rely on the same data context being present. This means in general you don't want the actual data context to be set anywhere in the view, i.e. not in the xaml and not in the code behind. This doesn't mean you can't bind to the properties by name. In my case I create a View/ViewModel pairing for every reusable control. The two go together everywhere just like an old married couple. The property names will never change. Not having a DataContext does mean that tools like Resharper will put a info icon under the property letting you know it couldn't find a DataContext to resolve the property against. Not that big a deal, and if you want, you can always set the design time DataContext to make sure you got the names right. You'll probably want to remove that design time context once you plan on reusing the control across multiple solutions. Here's how one tab in the final solution was structured.

A Real World Example

Working with the Reusable Control

The line item navigation box for this order entry system needs to be used on multiple tabs. On some tabs it will be nested directly within the the GroupBox that holds the line items on other tabs (like the one shown) it may be a level deeper inside a grouping of controls for the line items. The user control takes up only about 40 lines of xaml (included below) and does nothing more than allow the user to jump to a particular line item (there can be hundreds) and scroll that line item into view, or bring up a dialog allowing the user to search by the line item description and jump to that line item again bringing it into view. There is NOTHING in the code behind except the default call to InitializeComponent method call. All the logic for the control is in the LineItemNavViewModel. The question is where do I put a property that returns the LineItemNavViewModel such that the control can find it.

The Navigation

While the line item navigation box may be in one of several container controls, and those controls may themselves be nested in other controls, they all only make sense in the context of an actual order. Therefore I decided to add a property at the OrderEntryViewModel that holds my LineItemNavViewModel.

The question becomes: how do I reach up from inside a control that already has an assigned data context to a parent control an unknown number of levels above that has a different data context? It turns out it's not that hard. The syntax appears a little convoluted but the RelativeSource attribute is very flexible.

For the sake of completeness, let me specify how the parent container is used. The LineItemNavView sits in another control LineItemActionsView (the red outlined box in the image). The code for that row looks like this:

<Order:LineItemActionsView Grid.Row="0"
                        DataContext="{Binding LineItemActionVm}" />

You can see the DataContext is set to LineItemActionVm and not to the parent OrderEntryViewModel. In the LineItemActionsView.xaml I specify the LineItemNavView control as follows:

<Shared:LineItemNavView Grid.Column="1" 
                        DataContext="{Binding RelativeSource={RelativeSource 
     FindAncestor,AncestorType={x:Type Order:OrderTabLineItemsView}}, Path=DataContext.LineItemNavVm}" />

Shared: and Order: are just xmlns paths to the clr-namespaces that hold my xaml code for the respective user controls. The RelativeSource is specifying that somewhere up the chain of controls holding the LineItemActionsView is a user control of type OrderTabLineItemsView (the View that holds the entire tab). The Path portion of the binding says that I want to reuse the DataContext of that view, and in that DataContext there will be a property named LineItemNavVm that holds my LineItemNavViewModel.

There were two things that took me a while to discover, one was just the rather strange double use of RelativeSource, and the second was discovering that I had to explicitly state in the path, that I wanted the DataContext. It seemed obvious once I discovered it but without a rather casual reference to it on StackOverflow I might still be struggling.

In my case everywhere I reuse this control I'll be able to use this same Binding but that's only because in this application I know there will always be an ancestor Order:OrderTabLineItemsView. If there weren't it wouldn't be a problem, it just means I need to specify a RelativeSource that makes sense for the application where I want to use the control. Remember the reusable control knows nothing about its DataContext, it just references the properties on its ViewModel. As long as you specify where that ViewModel can be found, the control will work. In fact if I saw this particular control as being useful across multiple applications I would move it into its own assembly, or at least into an assembly with other related reusable controls.

There are other ways to use the RelativeSource binding. You can specify another control explicitly using an x:Type of UserControl and the AncestorLevel attribute to specify the level where the UserControl of interest can be found. This struck me as a rather fragile way to do things but nonetheless might be prove to be a useful technique to know about. Below as promised is the entire XAML of the little user control LineItemNavView. Those three properties, MaxLineItem, CurrentLineItem and FindLineItemCommand are all in the LineItemNavViewModel class (they are shown in red because the xaml can't resolve them because it doesn't know the data context.).

LineItemNavView xaml
 <UserControl x:Class="HssOrderTracker.View.OrderEntry.Shared.LineItemNavView"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
             xmlns:extToolkit="http://schemas.microsoft.com/winfx/2006/xaml/presentation/toolkit/extended"
 
             mc:Ignorable="d" 
             d:DesignHeight="300" d:DesignWidth="300">
 
    <GroupBox Header="Line Item Nav."
              Style="{StaticResource gbBackground}"
              Foreground="Black">
        <Grid Margin="0,0,0,2">
            <Grid.ColumnDefinitions>
                <ColumnDefinition Width="auto" />
                <ColumnDefinition Width="auto" />
            </Grid.ColumnDefinitions>
 
            <extToolkit:IntegerUpDown Grid.Column="0"
                                      Style="{StaticResource nudSpacingTight}"
                                      Minimum="1"
                                      Maximum="{Binding MaxLineItem}"
                                      Value="{Binding CurrentLineItem}"
                                      UseLayoutRounding="False"
                                      IsTabStop="False" />
 
            <Button Style="{StaticResource btnStyleNav}"
                    Grid.Column="1"
                    Command="{Binding FindLineItemCommand}"
                    IsTabStop="False">
                <StackPanel Orientation="Horizontal">
                    <Image Source="/Artwork/Find.png"
                           Style="{StaticResource btnImage}" />
 
                </StackPanel>
            </Button>
        </Grid>
 
    </GroupBox>
</UserControl>
 

For the insatiably curious here is the LineItemNavViewModel code:

LineItemNavViewModel
 using System.Windows;
using System.Windows.Input;
using HssOrderTracker.View.Dialogs;
using JetBrains.Annotations;
using Syncor.MvvmLib;
using Syncor.Ninject;
 
namespace HssOrderTracker.ViewModel.OrderEntry
{
    [IoC]
    public class LineItemNavViewModel : ViewModelBase
    {
        private readonly OrderEntryViewModel _orderEntryViewModel;
 
        public LineItemNavViewModel(OrderEntryViewModel orderEntryViewModel)
        {
            _orderEntryViewModel = orderEntryViewModel;
        }
 
 
        //Take and int and pass it to the OrderEntryViewModel which can turn it into a OrderLineItemViewModel
        //and raise the property change to the view.
        private int _currentLineItem;
        [UsedImplicitly]
        public int CurrentLineItem
        {
            get { return _currentLineItem; }
            set
            {
                if (value == _currentLineItem) return;
                _currentLineItem = value;
                _orderEntryViewModel.SetCurrentLineItem(_currentLineItem-1);
                RaisePropertyChanged("CurrentLineItem");
            }
        }
 
        [UsedImplicitly]
        public int MaxLineItem
        {
            get { return _orderEntryViewModel.LineItems.Count; }
        }
 
        #region FindLineItemCommand
 
        private RelayCommand _findLineItemCommand;
 
        [UsedImplicitly]
        public ICommand FindLineItemCommand
        {
            get { return _findLineItemCommand ?? (_findLineItemCommand = new RelayCommand(x => FindLineItemCommandExecute(), x => FindLineItemCommandCanExecute)); }
        }
 
        public bool FindLineItemCommandCanExecute
        {
            get { return _orderEntryViewModel.LineItems.Count > 1; } 
        }
 
        private void FindLineItemCommandExecute()
        {
            FindLineItemDlogView find_dlog_view = new FindLineItemDlogView(_orderEntryViewModel.LineItems);
            find_dlog_view.Owner=Application.Current.MainWindow;
            if ( find_dlog_view.ShowDialog() == true)
            {
                if (find_dlog_view.SelectedLineNumber != -1)
                {
                    CurrentLineItem = find_dlog_view.SelectedLineNumber + 1;
                }
            }
 
        }
        #endregion
 
    }
}
 

Visio and the L2100 Error

2011-10-06T17:16:00.001-07:00

Every now and then Visio for Enterprise Architects (and I suspect other versions) seems to to corrupt itself. While this is the version from 2003, it still appears to be the last one with full ERD support. I'll get an error about a relationship not connected at both ends. The only problem is the relationship is not visible on the diagram anywhere so there is no way to "fix" it, or delete it. Luckily I found a solution on Microsoft's technet forums. I'm just repeating here with some additional annotation the advice I found there:

Select Tools→Macros→Visual Basic Editor from the Visio menus (or hit Alt-F11).
Select Tools→References from the Visual Basic editor.
Check Microsoft Visio Database Modeling Engine Type Library and
click the OK button to dismiss the dialog. Yes, the are in alphabetical order, and notice this is under "Microsoft" not under "Visio"
If you don't have a code window open use the Insert → Module
Copy this subroutine shown below and paste it into the text area under General.
Select Run→Run Sub/UserForm (or hit the play button)

If you switch back to your ERD view and run a Model check again the error should be gone.

Credit to Chang Oh, Microsoft
 Sub DeleteAllDisconnectedRelationshipsFromAllModels()
 
    Dim vme As New VisioModelingEngine
    Dim models As IEnumIVMEModels
    Dim model As IVMEModel
    Dim elements As IEnumIVMEModelElements
    Dim element As IVMEModelElement
    Dim relationship As IVMERelationship
 
    models = vme.models
    model = models.Next
 
    Do While Not model Is Nothing
        elements = model.elements
        element = elements.Next
 
        Do While Not element Is Nothing
            If (element.Type = eVMEKindERRelationship) Then
                relationship = element
 
                If (Not relationship.IsFullyConnected) Then
                    model.DeleteElement(element.ElementID)
                    elements = model.elements
                End If
            End If
 
            element = elements.Next
        Loop
 
        model = models.Next
    Loop
End Sub
 

When Dispose Throws the Baby Out with the Bathwater

2011-09-30T11:39:00.000-07:00

As I said in my last post, there is a lot to like about .NET but every now and then they do some really screwy stuff. This post is about BinaryReader and BinaryWriter and why you shouldn't dispose of the them when you're done with them (or do the equivalent by putting them in using statements), unless you follow one particular idiom of usage. That idiom is the one you see in MSDN and in a lot of examples. Unfortunately, nothing I've seen in MSDN (or in my Nutshell reference) properly explains what is going on here.

The idiom typically wraps the creation of the stream inside the creation of the BinaryWriter e.g.

 using (BinaryWriter binWriter =
 new BinaryWriter(File.Open(filename, FileMode.Create)))
{
}
 

The enclosed call to File.Open returns a FileStream. A FileStream derives from Stream and all Stream's are disposable. Who owns it? Who should dispose of it? Looking at this example it seems obvious that BinaryWriter is the only one that can dispose of it. But what happens when you don't use this idiom? For example, assume you have a previously created Stream you're going to use for an extended period of time. Say you open a TCP connection with TcpListener and get the underlying stream:

 _serverTcpClient = _tcpServer.AcceptTcpClient();
_myClientStream = _serverTcpClient.GetStream();
 

Mostly you're going to use this stream directly via something like _myClientStream.Write(data, offset, size). But maybe there's a point where a BinaryWriter can help you; say you want to kick start communications with a protocol message:

 BinaryWriter w = new BinaryWriter(_myClientStream);
w.Write("Hello");
w.Flush();
 

If you strive to be careful about disposing of everything that should be disposed you probably think it would be better to write

Code Snippet
 using (BinaryWriter w = new BinaryWriter(_myClientStream))
{
    w.Write("Hello");  
}
 

Or at least to manually call w.Dispose(), but you'd only be right, if sending "Hello" is the last thing you ever want to do with _myClientStream. This is counterintuitive to me, the stream was created in another method in this class and lives in a member field, it seems obvious that BinaryWriter doesn't own this resource and shouldn't dispose of it when finished. The reason it behaves this way is because of the previous idiom where the stream is created in the constructor of BinaryWriter. This tells me this idiom is wrong and shouldn't be used but .NET decided (wrongly) that this was the only useful idiom that would ever be used so they dispose of the stream. It's just one of those little gotcha's you need to be aware of. Just keep the bathwater (the dog will drink it any way), it's better than throwing out the baby.

Not Well Connected

2011-09-29T10:58:00.001-07:00

Let me first say that I find .NET to be the best designed, easiest to use framework I've ever had the pleasure of dealing with in 30 years of programming. However, that doesn't mean they got everything right. The topic today is the Socket Connected property that lives in the System.Net.Sockets namespace.

You probably suspect that a property named Connected returns true if a socket is connected and returns false if it isn't connected. In fact it seems so obvious, that like me, you probably aren't too tempted to go read the docs on this property. That would be a mistake. A more accurate name for this property would be LastOperationSucceeded. Below is the relevant excerpt from the MSDN docs on the Connected property (emphasis is mine):

The Connected property gets the connection state of the Socket as of the last I/O operation. When it returns false, the Socket was either never connected, or is no longer connected.

The value of the Connected property reflects the state of the connection as of the most recent operation. If you need to determine the current state of the connection, make a non-blocking, zero-byte Send call.

I don't believe the docs are accurate. The Connected property returning false DOES NOT mean the socket is no longer connected. It just means the last operation failed. The difference is not pedantic and in fact designing code assuming Connected means there is a valid or invalid connection can easily lead to much confusion and heartache and ultimately a non-working design.

This became obvious to me because on the Server side of a connection (that sends data only) I wanted to know when the the client dropped the connection. The client drops the connection when it stops receiving data for a predefined amount of time. This means the last send by the server was a success so the server never knew the client was gone.

Equally important, on the server side I was checking Connected before doing a write to make sure the client was still connected. Big Mistake. In this application I shortened the send timeout to 50ms. If the client was too busy to get a frame of data it was no big deal I could just drop the packet on the floor. The problem was that after dropping the packet Connected returns false. That means the server would quit sending data after the first dropped packet. The client is in fact still connected but since the last operation failed Connected returned false.

The first problem caused a hard to find problem when the next measurement started. For some reason if a client reestablished a connection (the old one was still valid) within 3 minutes all was well. After three minutes the client connection would fail and the measurement would not work.

In my case since the client and server also exchange info through a WCF service my fix was to have the client directly inform the server about the end of the measurement, and force the server to disconnect. Now a client reconnecting always works. I also belatedly set the ExclusiveAddressUse to true. It being false (the default) may have contributed to the strange three minute reconnect issue.

If you want to tell if you can still communicate by doing a zero byte send here's a somewhat simplified version of the approach suggested from the above referenced MSDN docs. _serverTcpClient is the TcpClient field that was returned from the TcpListener call to TcpAcceptClient(). However, I don't even recommend this because this again, it isn't really telling you if the connection is valid, just if this operation worked.

ConnectionIsValid
 private bool ConnectionIsValid()
{
    if (_serverTcpClient == null) return false;
 
    Socket client = _serverTcpClient.Client;
    bool blocking_state = client.Blocking;
    bool is_connected = false;
    try
    {
        byte[] tmp = new byte[1];
        client.Blocking = false;
        client.Send(tmp, 0, 0);
       return  client.Connected;
 
    }
    catch (SocketException e)
    {
        if (e.NativeErrorCode.Equals(10035)) //send would block
          return true; 
        else
        {
          return false;
        }
    }
    finally
    {
        client.Blocking = blocking_state;
    }
}
 

Forcing WPF Controls to Update

2011-09-01T15:31:00.001-07:00

One of the nice things about WPF is how easy it makes implementing MVVM. You can easily decouple the view from the logic that affects the view. Every application I write needs to disable and enable certain controls. Recently I was working on an application that plays back data files.

The figure at the left shows both the user interface and an example plot. The program opens a data file. Then when the user hits play, a separate thread starts playing back the data in the second window. Everything worked perfectly in WPF using MVVM until the end of the data file was reached.

I know from my WinForm experience that updating the UI from a separate thread is a no-no (OK the official term is cross-threading violation). No problem, there are multiple ways I can get things to happen on the correct thread. I decided in this case to move from my home-rolled thread to the BackgroundWorker class that .NET provides. I set up the thread start method as the DoWork event handler and hooked up a ProgressChanged event handler. Finally, I set the property WorkerReportsProgress to true.

Now when all the data is read from the file, I just call the ProgressChanged method. The final key was determining which method to call to make the form properly update. Application.Current.MainWindow.UpdateLayout() or the related InvalidateVisual() methods seemed like good candidates. Turns out they didn't work. Since the buttons implement ICommand, indirectly through the RelayCommand pattern I needed to get the form to check for a change in the underlying state. Luckily I did eventually discover just such an animal . All the progress changed handler had to do was make a single call to:

CommandManager.InvalidateRequerySuggested().

How to Find Anything in Outlook 2010

2011-08-03T11:50:00.001-07:00

My Old Way

I've never been crazy about trying to find things in Outlook. I used to use the Advanced Find feature and I just memorized the Shift-Ctrl-F shortcut because since Microsoft went to the ribbon bar I could never find it. The only problem with this search is it takes quite a few clicks to configure as you can see in the figure. It's particularly easy to forget to enable the Search subfolders checkbox. This approach is still worth knowing but recently I've found some of the features in Outlook 2010 to be more useful in most cases.

Find the Search Box

At first discovering how to search is a bit annoying. Search as you might through the ribbon, you won't find a search tab or any search items. Seems highly bizarre to me to hide the search tab, but as I've mentioned in past posts Microsoft seems to take perverse pleasure in anti-discoverability. Maybe it's a rite of passage thing with them. Once you stop looking in the ribbon bar you will notice that for each major type of outlook item (Mail, Calendar, Contacts etc.) there is a search field. It's typically in the upper right hand corner, not too hard to find, but in my typically large Outlook window not exactly in my line of sight either. You can play hunt the search bar in the image below, but the green arrow is a big hint. Still this search method is not very effective for me.

Using the Right Search Box

The default search box limits itself to whatever folder you are currently in. That is not typically what I need when I'm searching. I have contacts divided up into multiple contact lists (otherwise all 600 contacts would sync onto my cell phone). I just want to find a person and I don't want to search across all five lists. Luckily it's easy, but it's in that hidden Search tab. When you click in the search bar the Search Tab shows up.

Microsoft highlights it in orange so you can't miss it (although I still did the first several times I searched, I don't know why, I guess I just don't expect critically useful tabs to hide themselves). It's also important to note that this tab's content will change based on which type of object you are searching for. The above image is for mail.

The one at left is for contacts. It's the All Mail Items and All Contact Items that I find the most useful. So useful in fact that I don't want them on a ribbon tab that doesn't show up. Luckily there is a solution. Right click on any item you find useful and select the Add to Quick Access Toolbar. I've already done that in the image so that option is grayed out for me, however if you look up above in the quick access bar (see the blue arrow), you can see the icon button for searching all contact items. Now whenever I want to search contacts, mail or the calendar I click the appropriate icon, Outlook automatically puts me in the search box and I start typing.

In an attempt to keep a feature for Outlook 2013, Microsoft only enables the search icon for the current section of Outlook. If you're in the contacts, you can search contacts, if you're in mail you can search mail. There appears to be no technical reason for this other than to annoy you. However, you can work around it by adding the "All Outlook Items" to the quick access bar. This works from all areas of Outlook. Happy hunting, keep an eye out for grues.

WPF Data Binding Booleans: To Be or !To Be

2011-07-28T23:31:00.001-07:00

The road leading towards WPF mastery hit a small bump when it came to data binding and Booleans. I wasn't surprised when my first attempt didn't work, I wasn't even sure what I expected to happen. Normally Boolean fields have some automated behavior. When they are grouped, clicking one button true sets the others in the group false. How does this play with data binding where the value for the field is supposed to be set by the binding? It's enough to make me think if Scott Meyers's were writing a book on this he would have an item titled Prefer CheckBoxes. Checkboxes work with simple Binding to IsChecked just like you'd expect. I do have customers though that insist on Booleans because they like to see both options explicitly shown, so here's one solution:

Command Binding

Edit: Turns out you don't really need the command binding. Just using two properties as described below is sufficient. I'm leaving the code snapshots as they are both you don't need to bind to Command and you don't need to write the two commands.

One way to get Booleans to behave with data binding is to bind not just IsChecked but also bind the Command as shown below. This XAML creates two radio buttons labeled To Be and Not To Be. In my final code I added a Mode=OneWay to the binding, but it appeared to work no differently with the default binding.

XAML Snippet
 <RadioButton Content="To Be"
             IsChecked="{Binding ToBe}"
             Command="{Binding ToBeCommand}" />
<RadioButton Content="Not To Be"
             IsChecked="{Binding NotToBe}"
             Command="{Binding NotToBeCommand}" />
 

The ToBe Property is pretty standard except it also sets the property and raises the event for NotToBe. NotToBe is just an automatic property. Both commands will be implemented, but they will both set the ToBe property, one will set it to true and the other will set it to false. Here's the full code example:

Properties and ICommands
 private bool _toBe;
public bool ToBe
{
    get { return _toBe; }
    set
    {
        _toBe = value;
        NotToBe = !value;
        RaisePropertyChanged("ToBe");
        RaisePropertyChanged("NotToBe");
    }
}
 
public bool NotToBe { get; set; }
 
private RelayCommand _toBeCommand;
private RelayCommand _notToBeCommand;
 
public ICommand ToBeCommand
{
    get { return _toBeCommand ?? (_toBeCommand = new RelayCommand(x => ToBeExecute())); }
}
 
private void ToBeExecute()
{
    ToBe = true;
}
 
public ICommand NotToBeCommand
{
    get { return _notToBeCommand ?? (_notToBeCommand = new RelayCommand(x => NotToBeExecute())); }
}
 
private void NotToBeExecute()
{
    ToBe = false;
}
 

Dependency Walker

2011-07-25T04:28:00.000-07:00

Conjures up images of ice planet Hoth doesn't it. While it may not be as fearsome as an Imperial Walker the you'll find Dependency Walker to be much more deadly in killing off .DLL problems. If you've ever built an application on your development machine and then had it not run on a target machine, this app needs to be in your arsenal. It's also indispensable for troubleshooting remote debugging and 64/32 bit BadImageFormatExceptions. There are 32 and 64 bit versions of Dependency Walker available. If you develop on a 64 bit machine download both. If you target anything to a 32 bit machine you'll want to run the 32 bit version against the .exe or .dlls you deploy on the 32 bit machine.

The image shows a few key features. When you load an .exe use the Profile menu and run Start Profiling to check out your delay loaded .DLLs.

Also you'll probably want to run it directly on any .DLLs that are giving you problems. When a .dll not found exception occurs you'll notice the message says either the .DLL or one of its dependencies can't be found. In my experience it's those dependencies that cause all the problems. You can see from the blue arrow in the image that two .DLLs have yellow icons. In this particular case those two .DLLs aren't a problem, but usually others that show up in yellow very may well be.

Finding 32/64 bit problems is even easier, you can click on the CPU column (shown by the lower green arrow) and then scroll down and if you are trying to deploy on a 32 bit machine and the column has x64 instead of x32 you've found the problem causing .DLL.

You'll probably get some false positives from DW but a few quick web searches will usually let you identify those and focus in quickly on the .DLLs that are causing you grief.

Mac Users - Check Your Lion Compatibility

2011-07-22T10:09:00.001-07:00

I've seen some complicated methods involving the Terminal for finding existing applications on your Mac that won't run with Lion, the latest OS from Apple. In case you don't know Apple is dumping support for "Rosetta", the technology that allows applications written for PowerPC-based computers to run on the newer Intel-based Macs. There are some notable casualties of this, including Quicken 2007 and Office 2004. You might want to know before you upgrade which of your applications aren't going to work anymore.

The GUI Way To Find PowerPC Apps

Apple being Apple you know there had to be a non-terminal way to do this right? Use the Finder’s Apple menu and select About this Mac. In the resulting dialog click the “More Info…” button. Wait a minute or two for the list to populate. Widen the window if necessary to show the “Kind” column. You can click on this column to sort by Kind. Then you can scroll to the “PowerPC” applications to see all your applications that won’t run under Lion.

I have about 400! applications that will no longer work. To be fair, most of these are in a folder that contains the contents of an old hard disk I copied over. Out of the entire list there were a only a few that I think might affect most people, couple of games, Quicken 2007 and Microsoft Office X. Your list will almost certainly be shorter and easier to review than mine. However, it's still worth doing to make sure you don't have any applications you can't live without.

BadImageFormatException When 64 meets 32

2011-07-21T12:02:00.001-07:00

What the Exception Said

It said "BadImageFormatException" Obvious right? Nice clear use of the term "Image" as you go off looking for a bad. jpg, .png. or gif file.

What the Exception Should Have said

Expected64BitDllGot32BitDllException – OK you can probably get a BadImageFormatException for other reasons, but every time I've seen it, this is why.

When Any CPU Doesn't Help

If you stick to the managed world of C# you'll probably never see this exception. If you write a .DLL in C++/CLI with common language runtime support set to /clr (under Project Properties as shown in the image), you'll almost certainly see it.

I was wrapping an unmanaged C++ DLL in a managed /clr wrapper when I ran across it. What happens is that the compiler will create either a 64 bit or 32 bit version of your .DLL. The advanced linker settings as shown in the image allow you to set the target machine.

When Worlds Collide

The problem occurs when you host the .DLL in a managed application that supports Any CPU (or specifically a 64 bit model). If you test on a 32 bit machine you won't see a problem. Your hosting managed application will run in 32 bit mode and it will load the 32 bit .DLL without issue. When you run on a 64 bit platform your hosting application will run in 64 bit mode and when it goes to load the DLL (remember it's dynamically linked) it will throw the BadFormatImageException because it can't find a 64 bit version of the .DLL.

One Love One Heart

The easy solution is to have one world. Use the properties dialog of your managed application as shown in the image and force the hosting application to be 32 bit. Since 32 bit applications will run on a 64 bit machine under WOW your problem will be solved. If for performance reasons you want to have your application run in 64 bit mode under 64 bit machines, I suspect you will have to build your .DLL twice. Once for each target machine. I've never done this but I suspect you just create distribution folders with the proper .DLL and it will work.

WPF Validation on calculated fields

2011-07-14T11:45:00.001-07:00

I'm working on a WPF application that uses a WCF service. The service communicates the GUI changes to a radar that runs on a separate computer. The WCF service also runs the parameters through a radar equation. The system parameters are such that at extreme values for all the fields the system can generate an invalid state. Typically the sampling rate becomes faster than the allowed. Since it's unclear which parameter the user will want to back-off, a good solution is to just show the calculated values and indicate when one of them is in error. Of course I also disable the Run button so there's no chance they actually try to command the system into an invalid state.

WPF Validation via IDataErrorInfo

There are many ways to achieve validation using WPF, including custom properties, XAML that checks for exceptions and the method I ended up using; implementing the IDataErrorInfo interface. This interface only has two members and only the indexer property this[string] needs an actual implementation, since you don't have to use the Error property. Given that the property bound to the displayed sampling rate widget is called SamplingRate here's a simple validator:

public string this[string columnName]
{
    get
    {
        switch (columnName)
        {
            case "SamplingRate":
                if (_samplingRate > MAX_SAMPLING_RATE_MHZ)
                {
                    return String.Format("Sampling Rate may not exceed {0} MHz.",MAX_SAMPLING_RATE_MHZ);
                }
                break;
        }
        return "";

    }
}

Returning a non-empty string for any property that matches columnName indicates a validation failure returning an empty string indicates the validation passed.

Now in my xaml I just turn on the validation by adding the ValidatesOnDataErrors like this:

Text="{Binding SamplingRate, Mode=OneWay, ValidatesOnDataErrors=True}"

Now when the validation is violated a red border appears around the text box with this attribute. This is the default handling for validation errors. Unfortunately, the nice message I returned is nowhere to be seen.

Showing your Validation Message

I'm not sure why the default behavior is to not show your message. It seems quite reasonable to have the message show up as a ToolTip by default. My solution was to to create a Style that retrieved the message and put it in a tool tip as shown:

<Style x:Key="ValidationHandler" 
        <Style.Triggers>
        <Trigger Property="Validation.HasError"
                 Value="True">
            <Setter Property="TextBox.ToolTip"
                    Value="{Binding RelativeSource={RelativeSource Self}, 
                             Path=(Validation.Errors)[0].ErrorContent}" />
        </Trigger>
    </Style.Triggers>    
</Style>

The Problem with IsEnabled

Only one problem, it didn't work. When showing calculated fields I typically set the IsEnabled flag to false. The user not only can't make changes but they get a pretty decent visual indicator that changes aren't allowed. Turns out that when a TextBox (and maybe all controls) are disabled the tool tips don't show up. I'm not sure why and there may be a better work-around but since I already had the style, I did my best to fake the disabled behavior. Here's the new xaml for the control:

<TextBox Style="{StaticResource ValidationHandler}"
          IsReadOnly="True"
         Text="{Binding SamplingRate, Mode=OneWay, ValidatesOnDataErrors=True}"  />

I've set the IsReadOnly flag and removed the IsEnabled flag in the xaml for the control itself. You can also see how the ValidationHandler is hooked in. The new Style will take care of the IsEnabled flag. When no error is found IsEnabled will be false. If an error is found it will set IsEnabled to true and set the background gray (IsReadOnly is left set to True in both cases). The downside is the user will still be able to click in the read-only box and highlight the value, but the TextBox will look like the disabled version and the user still can't make any changes.

<Style x:Key="ValidationHandler" BasedOn="{StaticResource nudSpacing}">
    <Setter Property="Control.IsEnabled"
            Value="False" />
    <Setter Property="Control.Background"
            Value="#F3F3F3"/>
        <Style.Triggers>
        <Trigger Property="Validation.HasError"
                 Value="True">
            <Setter Property="TextBox.ToolTip"
                    Value="{Binding RelativeSource={RelativeSource Self}, 
                          Path=(Validation.Errors)[0].ErrorContent}" />
            <Setter Property="TextBox.IsEnabled"
                    Value="True"></Setter>
        </Trigger>
    </Style.Triggers>           
</Style>

Now when the user violates the validation and puts the cursor over the field they see:

Treating XML files as Content

2011-07-12T11:54:00.000-07:00

I like keeping a lot of my application settings in a plain old XML data file. I've found the way Visual Studio treats it Properties.Settings file to be more complicated than I like. The only thing I store there is the name of my xml application settings file. I mentioned in a previous post on using the MSI installer in Visual Studio that I keep my xml files set as content and this generated some feedback about exactly how do to that, prompting this blog.

The Solution Explorer is the place to be.

The easiest thing to overlook is that the properties on a particular file can vary depending on where you click on it. For instance if you open an XML file and click on its tab or inside its content you will see a property dialog similar to the one shown at the left. You be justifiably confused about not being able to find the property for setting the file as content.

Instead you need to use the Solution Explorer and click on the .xml file there. You'll notice the Property dialog changes and now you have a Build Action property which you can set to Content and a Copy to Output Directory property to control how and when the copy happens. Most of the time I keep this set to Copy always because I want changes I make in the design environment to propagate to the application I run while Debugging.

Signal Processing on Windows in Real Time

2011-07-09T12:56:00.001-07:00

You don't typically see Windows and Real Time in the same sentence. However, there can be some significant advantages to doing real time signal processing under Windows. This post was inspired by several questions posted on StackOverflow that got closed. I think they were good questions but they don't allow for succinct answers and that seems to violate the monitors sensibilities so I thought a longer form blog post might help some of those questioners.

You say Tomato I say That's not Real Time

So the first question is what's real time? It's a surprisingly hard thing to meaningfully define for the uninitiated but I'm going to try. The primary requirement is that the system exhibit a certain amount of deterministic behavior. This means, that if you need say micro second level responses, that the system reliably and repeatedly will give you microsecond level responses. It can't honor microsecond level timing "most" of the time but every now and then go off to service a daemon or a garbage collector and be gone for 50-100 milliseconds. So at the microsecond level it would appear Windows doesn't cut it, but in fact there are hardware ways around this problem. On the other hand if your real time requirement is hundreds of milliseconds Windows may be suitable without assistance. You might have to disable a lot of services (ala gamers) and you might need to take care with some garbage collected languages but it could easily work. If you need response time in the tens of milliseconds but the occasional hiccup isn't a problem, then I don't think of that as real-time, but again unadorned Windows may suffice. What follows is addressing the solution to the microsecond level deterministic requirement.

The Hardware Solution

The solutions I'm most familiar with are offered by Innovative Integration. II has a series of cards that plug into the PCI backplane that can do a variety of functions and contain FPGAs so you can extend them to do exactly what you want. The cards contain enough buffering that even if the hosting OS is busy for hundreds of milliseconds (or possibly even longer) no data will be lost. This is critical in many of the radar applications I have written. In those applications I will know where the data starts and keeping track of things like the elevation and azimuth angles is done simply by counting the data. A dropped packet would invalidate the entire run. The systems I 've worked on using the Innovative Integration cards have never dropped data and proven to be extremely reliable. The most recent systems I've developed have used their ePC solution. The signal processing happens on a separate computer running Windows XP (the box comes with XP embedded but limitations on .NET and XP Embedded led us to upgrade the OS).

Integrating With Windows

The real-time stuff is being handled by PCI cards or a separate Windows computer with similar hardware. How does one solve the impedance mismatch between Windows timing and the real-time performance of the hardware? A lot depends on the problem you are trying to solve. If as in my case you are collecting radar data, it is the collection of the data, not the display of the data that is critical. I design my systems to make the first priority to store all the data to the hard drive. The next priority is to stream the data out the TCP port for display or additional processing. At this point I can tag the data with elevation and azimuth information so dropping chunks of data is not catastrophic. In fact the typical system collects way more data than a human can analyze in real time so there often is no problem in decimating the data stream being sent to the display.

C++/CLI to the rescue

The biggest problem can be the tools you use. The libraries for a real time system are typically going to be written in a systems level language (a language that compiles to the metal) like C++. Writing your control software in C# can provide some interesting challenges when talking to those libraries. A particular pain point can be the handling of events. I found it impossible to wire up C# event handlers to the C++ events. However, writing thin wrappers in C++/CLI proved to be extremely beneficial. C++/CLI has a lot of facilities for bridging the gap between the managed world of .NET and the unmanaged world happening in the C++ libraries. Originally, I wrote a lot of code in C++/CLI but as grateful as I am for the language and its features I found the code I wrote in C++/CLI required more knowledge and sophistication to maintain properly. Eventually I migrated as much code as I could to C# and left the C++/CLI as the minimal wrapper. In the end this solution worked very well.

There are alternate solutions as well. In fact II provides example solutions written for three environments, Visual Studio (straight VC++), Borland C++ Builder (again straight VC++) but BCB has C# like form designers (I should really say that C# has BCB like tools). They also have examples using the Qt framework.

WCF also Helps

In the case of the ePC where all the processing is happening on a separate computer (usually headless and rack-mounted), I found that a simple WCF service was quite helpful. My GUI was written in C# on a remote computer on the LAN. Every change on the GUI was sent to the WCF service. The service also ran through a series of radar equations and modified dependent parameters. The dependent parameters were then updated on the GUI. It turns out that connecting to the WCF and making the first call is slow, but every call thereafter is quite fast. I made sure the first call happened during the boot phase. After that, users of the system had no idea a remote service was involved. The updating of the screen appeared in "real time" to the user (note that humans aren't microsecond sensitive creatures for the most part).

Plotting the Results

While the .NET world offers a lot of plotting packages, I had trouble finding any that bill themselves as "real time", or even near real time or anything but static. I needed a fast dynamic PPI (polar) plotting capability. We were already using MatLab for the FPGA programming and it turns out MatLab plotting is very fast and proved to be capable of sustaining the frame rates needed by the system. Again, I wrote the low-level code in MatLab's native language (using the object oriented variant helped). I then wrote wrappers to all the MatLab calls in C# and integrated the plotting window into my main C# GUI. Both the GUI and a plot of some synthetically generated data can be seen in the figure to the left.

D Programming Language–First Steps

2011-07-06T17:31:00.001-07:00

I recently purchased Andrei Alexandrescu's The D Programming Language. I don't have an actual need to learn D but I know Andrei is an engaging writer and I wanted to know more about D. Of course, books on new programming languages are more fun to read if you can take the language out for a test drive. I didn't have a D Compiler so I decided I should try and find one. Turns out this isn't very hard to do. The author of the language Walter Bright has a free D compiler available on his web site. Of course it's even more fun to use a programming language inside an IDE and it turns out there are plug-ins for both Eclipse and Visual Studio readily available (and possibly others but these are the two I use). The Eclipse project I tried is called DDT, and you can find it on the google code site. The project I used for Visual Studio 2010 is called Visual D.

I made a screencast on taking those first steps of installing the compiler and IDE plug-ins. I then broke the screencast up into three pieces so you can just watch the pieces that interest you. Part 1 is on the DMD compiler itself, part 2 tackles the Eclipse Helios install and part 3 walks through the install for Visual Studio 2010. I make a mistake while locating the DMD folder for Visual Studio as it wants a different folder than Eclipse. This installation error results in a compile time problem. I annotated the screencast with my mistake so you won't make the same one, but I also show you how to fix the problem inside Visual Studio.

Update: I also found a couple of other interesting sites if you're interested in writing Widows Forms (GUI) applications. Check out the D Forms Library and Entice the related GUI builder (drag and drop form creation similar to what you do in Visual Studio WinForm apps).

Part I – Installing a D Compiler

Getting and Installing a D Compiler

Part II - Eclipse

Getting and Installing the D Language Support in Eclipse

Part III - Visual Studio

Getting and Installing D Language Support in Visual Studio

System File Checker

2011-07-02T12:03:00.000-07:00

I've railed against Microsoft before for how they seem to specialize in anti-discoverability of features in their programs. This also applies to utilities that come with the operating system. There's a nifty little tool called System File Checker. SFC is designed to scan your system files and replace any incorrect versions. Doesn't this sound like either something you should know about or something that should run automatically? Isn't this just as important as system updates? Why would I want to keep around incorrect versions? Couldn't it at least run automatically in VerifyOnly mode? I was having an issue where the Windows Desktop Manager kept quitting on me. This would hang up my mouse keyboard and monitor for over a minute. It would only happen a couple of times a day but it was still a nuisance.

I lived with it for it for quite a while before I discovered sfc. I ran sfc from a command prompt. Under Vista and Windows 7 you want to right-click on your Command Prompt shortcut and select Run as Administrator.

Just typing sfc in the command prompt will give you some information on the various options for the tool. Pick your poison and let loose the dogs of cleanup. This solved most of my desktop manager issues, since it identified some files that needed to be updated. Now the desktop manager only goes on strike about once a week or so.

Cleaning up Floating Widgets on your Screen

2011-07-01T11:54:00.001-07:00

I'm running Windows 7 and every now and then I end up with an item from a menu or combo box floating on my screen. It's like a little lost puppy that can't find its way home, only way more annoying. The left over drek typically clutters my screen until I restart. I found an easier way for the widget to find its way back home:

Under Control->Panels –>Performance Information and Tools->Adjust Visual Effects

Turn off the checkbox for Use Visual Styles on Windows and Buttons. It takes a minute or more to reconfigure your display, be patient. I then turn it back on. In the meantime the floating widget found its rightful place and is no longer hanging around on my screen.

Counting Characters in Outlook

2011-06-27T12:14:00.001-07:00

I hate texting. I've been touch typing since my Mom brought home that Olivetti back when I was in middle school. That's long enough ago that my brain and fingers no longer have a direct connection. My fingers know how to type all by themselves. The problem is when I go to text (with one of those little teeny-tiny keyboards on a phone – I become the world's slowest hunt and pecker, I have to pretend to touch type every time I want to find "b". So my solution is to just send texts via email . As far as I can tell every cell provider has an email suffix for this. You type the persons phone number followed by the proper email domain suffix.

Can you count to 160?

The point of this post is the problem with using email to respond to text. Unless you tweet, it's hard to gauge just how short 160 characters is. If you exceed that length your message might just get truncated or split into multiple text messages. So the key is to know just how many characters you've typed. You can do this in Outlook 2007, but it's far from obvious how. Ideally you would want something showing you the count as you type (like even the most dimwitted text editors do). I haven't found this in Outlook yet but at least there is way to do it on demand. Spell check. Yep, that's right. The feature you always use but never invoke manually.

Hiding right there at the bottom is Word Count…, type your message and click it and you'll get a dialog similar to that shown at the left. Now if you look carefully at the first image above, you'll notice the Word Count… icon in the quick launch toolbar at the top of the window. That's not there by default, but you can easily add it.

Click the little drop down arrow on the right of the quick launch bar and select the More Commands… option as shown in the image at the left. You'll get the dialog shown in the image on the right. In that dialog follow the green arrows, choose the Message Tab, scroll to the bottom and choose the Word Count… command, click the Add>> button and Word Count… will show up in the right pane. Click OK and the command should now be in your quick launch bar. One final tip.

Hold down the Alt key. A series of characters will litter your screen. You'll notice on mine that 6, corresponds to the word count. That means I can hit Alt-6 and the word count dialog will appear on my screen. Now if I could just curb my verbose writing style I might like texting.

Project Locker No Space Left on Device

2011-06-26T11:01:00.000-07:00

The other day I tried to commit my changes and received the error message that's the title for this post. Nothing strikes fear into the heart of a coder faster than a failure on the source code management system. At first I thought maybe I had just exceeded my limit and had to pay for more storage, but when I went to the site I was under 50%. I was perplexed but luckily for me, too busy to worry about it right then. I tried a few things but nothing worked. Later in the day I came back to the problem and unlike a programming error, this problem magically disappeared. I suspect the server hosting my database actually ran out of disk space and it took ProjectLocker a couple of hours to rectify the situation. So if you come across this error your best bet may be to just be patient and wait for the tech gurus to swap in a new petra-byte hard drive. Luckily in all the time I've been using ProjectLocker this is the first time this has happened.

The Visual Studio MSI Installer

2011-06-24T05:00:00.000-07:00

The Click Once installer in Visual Studio is very discoverable and I've known about it and used it for years. I don't like it but I've used it, especially when a project has multiple dependencies. Much less discoverable is the fact that a more standard MSI installer is also included in Visual Studio. Why am I always the last to find out? Here are some step by step instructions for creating an MSI installer from inside Visual Studio 2010.

Step 1.

Right-click on your solution and choose Add-> New Project…

Step 2.

Open up the Other Project Types->Setup and Deployment->Visual Studio Installer (OK it wasn't that hard to discover but I seldom get past the Visual C# option. ) Enter a name and hit OK.

Step 3.

Walk through the wizard. In my case when selecting files I only needed to select the Content Files and Primary Output. I have an xml file that resides in a XmlData folder that must get created but since I marked its build property as content the wizard will take care of that automatically.

Step 4.

When the wizard is done you should have a new project and a new pane called File System should be open. If it's not you can right-click on your new project and select the View menu and select the File System option. You'll notice there are several other interesting options that deserve further exploration in the future.

Step 5.

If you want shortcuts to your application put in the Start menu and on the desktop, you have a couple of steps left. Also, I want my shortcuts to have the proper icons, so I'll include the steps for that. In the File System pane click on the Application folder and then in the right pane right click on the Primary output as shown and select the option for creating a shortcut as shown.

Step 6.

Click on the created shortcut and give it a better name. Then in the properties pane locate the Icon option and from the drop down select (Browse…) as shown at left.

Then in the dialog click the Browse… button (see the figure below). In the Select Item in Project dialog select the Application Folder at the top, select Executable Files (*.exe) from the Files of Type drop down and click on your primary output (as shown below) to pick the icon you associated with your application. This will result in the second dialog shown below where a small version of your icon is shown. Don't worry the appropriate size will be shown for the shortcut. Click OK and then drag the shortcut file into the User's Desktop folder. You can repeat this process again and drag the second copy into the User's Programs folder. In the User's Programs menu if you want to group your choices under your company name you can add a folder like I did in the above dialog for ITS-9202 and drag the shortcut into that folder. As you can tell I dragged the shortcut there before I set the icon. The order you perform these steps is not important.

Step 7 (The Final Step)

In the Solution Explorer right-click on your new install project and select Build. When the build finishes you can right-click again and select Open Folder in Windows Explorer and go try out your new installer. There are separate folders for your Release and Debug configurations so be sure to build both. Each folder should contain a setup.exe and the associated .msi file. I only ever use the Release version for the copy sent to the final client.

More Optional Steps

You can click on the installer project and then check out the properties panel to see many other options that can be set. There are also option panels for each of the folders in your project. Examples of both property panes are shown to the left and below. I've marked a few of the items in the project properties that I usually change. Your choices for customization aren't limited to what I've shown here, but this is as far as my experience has taken me.