Monthly Archives: July 2009

by dkt

Mark Buherle is looking for more records to break

A no-hitter, a perfect game, and 45 consecutive batters retired without reaching base. He went 49 consecutive starts going six or more innings (ended on a boneheaded ejection with two outs in the 6th in Baltimore after hitting a batter—I’m never going to forget what a demented call that was) And he does it with an 87 mph fastball. Who needs a power arm when you can have a crafty lefty who knows what he’s doing?

Baseball wasn’t all that big where I grew up, so I didn’t really follow the sport until I moved to Chicago near where the White Sox play. I decided that if I was going to be stuck in traffic every summer when the Sox were in town, that I might as well root them on. Buherle pitched the baseball game I ever saw live, and—big surprise—the White Sox won. It’s a shock when he loses, and it’s joy when he’s on the mound.

Congrats, Mr. Buherle: you show the rest of us what determination and effort can get you. It truly is incredible… —DKT

by dkt

A Hello World Order Entry app in WPF

So you’ve decided that Windows Forms is more trouble than its worth. You’re all set to start writing a WPF app. You fire up Visual Studio 2008, create a new solution, and see absolutely nothing about this fancy MVVM that seems to have taken the world by storm. No standard template—just a “WPF Application” that, when you start it, gives you the same blank Window that you used to get when you were creating Windows Forms apps. Really?

To be fair, I don’t think even the gang in Redmond realized just how far the community would run with MVVM and a lot of what we think of as staples of MVVM design now simply weren’t even thought of when Microsoft was trying to rush VS 2008 out the door. Visual Studio 2010 will provide better out-of-the-box guidance in creating a well-factored WPF app, but that’s not here quite yet.

Until then, give Order Entry a whirl. It’s a simple app with a simple purpose—provide a simple order entry ticket (buy/sell, symbol, price, and quantity). It sets up the basics of defining a view and a viewmodel that exposes the properties of a model in a way more conducive to consumption by the view.

It illustrates:

  1. Binding a view to a viewmodel
  2. Separation of the view (visual elements) from the viewmodel (data, non-visual resources)
  3. A simple ICommand implementation that disables/enables the Submit button

It’s not perfect because it lacks two things that every real GUI has (which we’ll fix in later posts):

  1. Threading. When you press Submit, all the “work” happens on the GUI thread.
  2. Validation. When you type something in the view that is not physically storable in the viewmodel (like entering in “Abracadabra” as a quantity), the screen changes to indicate an error on the field, but it doesn’t stop the user from submitting (viewmodel and its ICommand don’t know that the view is in an error state—only the view knows).

Validation and WPF data binding are tricky to get right. We’ll talk about that in later posts too. But for now, here’s version 1 of the Order Entry app to chew on. —DKT

by dkt

Windows Forms is a Maintenance Risk

People say that WPF is a pretty big change from the Windows Forms technology of yesteryear, but there are also people who have invested considerable time and money into Windows Forms solutions that aren’t eager to rewrite their apps yet again. I can understand that—it takes time to develop things, and rewriting things for the sake of using the latest and greatest is not usually something that keeps projects on time and on budget.

But any new development should definitely be written in WPF.

Here’s a snippet of Windows Forms code that keeps a TextBox on the screen synchronized with a Quantity field on an Order object:

MyEditor.cs 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

public class MyEditor : UserControl
{
    private System.Windows.Forms.TextBox quantityTextBox;
 
    public MyEditor()
    {
        InitializeComponent();
    }
 
    private void InitializeComponent()
    {
        quantityTextBox = new System.Windows.Forms.TextBox();
        quantityTextBox.TextChanged += new System.EventHandler(quantityTextBox_TextChanged);
        // ...more auto-generated noise
    }
 
    public void SetOrder(Order order)
    {
        _order = order;
        _order.PropertyChanged += order_PropertyChanged;
        quantityTextBox.Text = _order.Quantity.ToString();
    }
 
    private void quantityTextBox_TextChanged(object sender, EventArgs e)
    {
        long qty;
        if (long.TryParse(quantityTextBox.Text, out qty))
        {
            _order.Quantity = qty;
            quantityTextBox.BackColor = Color.White;
        }
        else
        {
            quantityTextBox.BackColor = Color.Pink;
        }
    }
 
    private void order_PropertyChanged(object sender, PropertyChangedEventArgs e)
    {
        if (e.PropertyName == "Quantity")
        {
            quantityTextBox.Text = _order.Quantity.ToString();
        }
    }
}

And in WPF:

MyEditor.xaml 
1
2
3
4
5

<UserControl x:Class="MyEditor"
                         xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                         xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <TextBox Text="{Binding Path=Quantity}"/>
</UserControl>
MyEditor.xaml.cs 
1
2
3
4
5
6
7
8
9
10
11
12

public partial class MyEditor
{
    public MyEditor()
    {
        InitializeComponent();
    }
 
    public void SetOrder(Order order)
    {
        this.DataContext = order;
    }
}

Which one would you rather maintain? —DKT

by dkt

PowerShell Deployment Options are Awful

I once looked into using Powershell as a foundation for an application that was to be very heavily powered by scripts underneath. It seemed like an idea with a lot of promise—most of the libraries it was to work with were written in .NET, the users were comfortable with scripting, and it would have been easy to expose GUI components in a scriptable way (think VBA for Office)—however, actually getting the thing deployed would have been a totally different manner.

Most firms lock down end-user machines. This makes for a more secure and easier to manage network, but it makes deploying an application an absolute nightmare when an application requires a non-trivial installer and administrative privileges to use.

And that brings me to the title of this post. Powershell deployment options are awful. Considering that Powershell is written largely (exclusively?) in .NET, it’s unbelievable that an installer has to be run, files need to be installed in system directories, and registry keys need to be written. About 99% of what it does can be done in pure .NET, and any app written in pure .NET can be copied to a directory and run as long as its dependencies are in the same directory or in the GAC. Life would have been much simpler for me if I could just include the Powershell .NET assemblies, deploy them with my application, and run Powershell scripts.

And then let’s say I do end up being able to deploy PowerShell properly, with all its funky registry keys and whatever else that installer does; what am I supposed to do with any PSSnapIns that I’m dependent on?

Somewhere on the Microsoft campus, there needs to be a giant poster called “Lessons Learned”. It should include at least the following bullet points:

  • No Clippy. Cartoons don’t help people get work done—functional software does.
  • People like XCOPY deploy—installers are obnoxious.

Well, they removed Clippy from Office 2007. Right now, .NET apps are so simple to deploy it’s criminal. So what’s the deal with Powershell? —DKT