Hello there visitor from grumpydev.com, if you are new here, you may want to subscribe this site.
Skip to content


Finguistics – Behind the Scenes Video!

Introduction

While we were putting together Finguistics down at Microsoft in Reading, Nick Page was filming mini-interviews about the project, the process and Surface development in general; the result of which has just been released on YouTube.

The Video

The video has a definite “design” slant, so isn’t very technical, which is understandable given the nature of Surface development (designing the apps and the user interaction is FAR harder than actually coding them). Myself, Marc and the other techies do try to throw some technical jibber jabber in there to counter act all the design speak though, so it’s not all crayons and paintbrushes!

I’d like to also point out that I wasn’t told we were going to be filmed, so I didn’t get chance to do my hair OR my makeup, and I had been eating on expenses for 3 weeks at this point, and the camera adds a least half a stone.. and.. and.. 😉

Posted in Surface.

Tagged with , , , .


Substitute – Variable Substitution Utility for Config Management (FinalBuilder etc.)

Introduction

At Lightbox we use an excellent program called FinalBuilder for automating all of our builds, and managing the configuration for the various environments we build to (system test, user acceptance testing, production etc.) It’s a very powerful tool and our “scripts” allow us to produce and deploy a build from a particular branch/tag in Subversion, targeting a particular configuration, with the touch of a button.

Once you get used to putting the projects together, using FinalBuilder is a huge time saver. One of the features it gives you is the ability to substitute “tags” in a file with the corresponding value from a project variable; so for example you could substitute %ServerName% for the variable called ServerName in the project. While this is very useful, it does require several steps to set it up each variable:

  • Create the configuration file (or template) containing the %VARIABLE% tag.
  • Add the corresponding variable name to an INI file (FinalBuilder had native support for INI files).
  • Add the variable to the project.
  • Configure the project to load that variable from the INI file.
  • Add the build command to do the substitution (obviously you will usually do this once for all the variables).

While none of those tasks are particularly onerous, it is quite error prone when you are relying on your developers to perform each task, and does make writing “generic” scripts quite tricky. You may not even want your developers meddling with your build process in the first place!

Substitute Utility

As an attempt to get the same level of functionality as the FinalBuilder substitution, but without the extra steps, I put together a small utility that takes an input file, a “substitute” file to be processed and a series of “sections” to use to perform the replacement. So for example, if you had the following INI file:

[MAIN]
SVNServer=MySvnServer
SVNPort=80

[INT]
Server=IntServer
Username=IntUser
Password=Password

[SYS]
Server=SysServer
Username=SysUser
Password=Password

And a “substitute” file as follows (this obviously isn’t a configuration file, it’s purely a very basic sample 🙂 ):

Subversion Server: %SVNServer%:%SVNPort%

Server: %Server%
Details : %Username% / %Password%

Running it through the utility and specifying the MAIN and INT sections (I generally use a “global” section, then configuration specific sections) would give us:

Subversion Server: MySvnServer:80

Server: IntServer
Details : IntUser / Password

More Information

So there you go, it’s a very, very simple utility, and indeed very little code; but I thought it might be of use to people who might be using FinalBuilder, or even people doing “manual” configuration management. It currently only supports INI files, but adding support for other file format is just a case of creating a new VariableReader implementation and decorating it with a ReaderHandles attribute to signify what “mode” you want it to handle.

I’ve uploaded it onto CodePlex at http://substitute.codeplex.com/, so feel free to grab it, play with it, edit it or criticise it to your hearts content.

Posted in Substitute.

Tagged with , , , , .


Strange Problem – Unable to Connect to the ASP.Net WebServer on Localhost

Introduction

This problem appeared out of the blue in Visual Studio 2005 on my work laptop. Google didn’t help with a solution, so I thought a brief blog post was in order.

The Issue

Trying to launch any ASP.Net application on my local machine, either in debug mode or starting without debugging, started the Cassini ASP.Net Webserver just fine, but the browser just threw up an “unable to connect” error. Google seemed to suggest it might be a corrupt webserver exe, but it seemed to be running fine so I ignored that option. I tried manually specifying a port in the project settings, and even using telnet to try access the port on localhost from the command prompt, but even though the webserver was running, nobody was listening!

The Fix

After clutching at random straws for a while I did a “ping localhost” from the command prompt and noticed it was returning replies from ::1 (the IPv6 “loopback” address). I popped open my hosts file (c:\windows\system32\drivers\etc\hosts) and noticed that localhost was mapped to ::1, but not to 127.0.0.1. I have no need for IPv6 on my machine so I commented out that line and added:

127.0.0.1       localhost

Fired up Visual Studio, pressed F5 and voila – all fixed! I’m not sure why this was suddenly a problem, it just appears that Cassini just doesn’t like being accessed via IPv6, but this seems to be the solution if this issues bites you 🙂

Posted in ASP.Net, Visual Studio.

Tagged with , , , , .


WPF Bootstrapping, NotifyIcon, ShutdownMode and the Mysterious Vanishing Application!

Introduction

I’m currently working on a small utility called Hotwire, which should be released in the not too distant future. Part of the application consists of a “launcher” application that sits in the notification area (the bit by the clock :-)) and fires up various other parts of the app when the user needs them.

Originally I put it together as a WinForms app, which seemed logical as the NotifyIcon class lives in System.Windows.Forms anyway, but once I’d started putting the configuration dialog together, I realised how much I missed the Binding magic of WPF. Although shifting the app across to WPF was a relatively simple task, there were a couple of “gotchas” along the way.

The WinForms Way – Without a Window!

A lot of the samples you’ll see for using NotifyIcon in WinForms will create a Window, put the NotifyIcon class on the form, and hide the form on startup so all you’re left with is the icon by the clock. While this approach works, as this application doesn’t have a “main window” as such,  it seemed a bit naff to have a hidden Window lurking in the background that I’d never use.

To do things slightly more “elegantly” we can “bootstrap” our application manually with our own Main() method, and put together a class that creates all of the controls required for our NotifyIcon and it’s various menus. Our Main() method is very simple; we just set a few properties, instantiate our TaskTray class and call Application.Run() to give us our Windows message pump (if you don’t do the last part, your application will quit immediately!)

static class Program
{
    private static TaskTray t;
    
    /// <summary>
    /// The main entry point for the application.
    /// </summary>
    [STAThread]
    static void Main()
    {
        Application.EnableVisualStyles();
        Application.SetCompatibleTextRenderingDefault(false);
        t = new TaskTray();
        Application.Run();
    }
}

Now our TaskTray.cs file will intentionally look spookily similar to the code behind for a normal WinForms window. All we need to do in our constructor is create a Container, a NotifyIcon, a ContextMenuStrip to attach to it, and an icon for us to display. To maintain parity with a normal codebehind class, we will wrap all of this up into a method called InitialiseComponent:

public void InitializeComponent()
{
    this.components = new System.ComponentModel.Container();
    this.SysTrayIcon = new System.Windows.Forms.NotifyIcon(this.components);
    this.MainMenu = new System.Windows.Forms.ContextMenuStrip(this.components);
    this.aboutToolStripMenuItem = new System.Windows.Forms.ToolStripMenuItem();
    this.configToolStripMenuItem = new System.Windows.Forms.ToolStripMenuItem();
    this.exitToolStripMenuItem = new System.Windows.Forms.ToolStripMenuItem();
    this.MainMenu.SuspendLayout();

    this.SysTrayIcon.ContextMenuStrip = this.MainMenu;
    this.SysTrayIcon.Icon = new System.Drawing.Icon(this.GetType(), "myapp.ico");
    this.SysTrayIcon.Text = "MyApp";
    this.SysTrayIcon.Visible = true;

    this.MainMenu.Name = "MainMenu";
    this.MainMenu.Size = new System.Drawing.Size(114, 82);

    this.MainMenu.Items.Clear();

    this.aboutToolStripMenuItem.Name = "aboutToolStripMenuItem";
    this.aboutToolStripMenuItem.Size = new System.Drawing.Size(113, 22);
    this.aboutToolStripMenuItem.Text = "&About";
    this.MainMenu.Items.Add(aboutToolStripMenuItem);

    this.configToolStripMenuItem.Size = new System.Drawing.Size(113, 22);
    this.configToolStripMenuItem.Text = "&Configuration";
    this.MainMenu.Items.Add(configToolStripMenuItem);

    this.MainMenu.Items.Add(new System.Windows.Forms.ToolStripSeparator());

    this.exitToolStripMenuItem.Name = "exitToolStripMenuItem";
    this.exitToolStripMenuItem.Size = new System.Drawing.Size(113, 22);
    this.exitToolStripMenuItem.Text = "E&xit";
    this.MainMenu.Items.Add(this.exitToolStripMenuItem);

    this.MainMenu.ResumeLayout(false);
}

We can then hook some events up in the normal manner and we’re all done, and no Window classes in sight!

The WPF Way – Still Without a Window!

To port this to WPF we first need to add references to System.Windows.Forms and System.Drawing (for our Icon), once that’s done we need to roll our own “bootstrapper” so we don’t create a Window on startup.

By default, when you create a new WPF application, you will get Window1.xaml and App.xaml. The latter contains a StartupUri property that the generated code behind uses to bootstrap the application and display the main window. If we nuke App.Xaml from the project (we’ll get a duplication Main() error if we don’t), we can add our own bootstrapper which looks very similar to the WinForms one above:

class BootStrap
{
    static TaskTray _taskTray;

    [STAThread]
    static void Main()
    {
        Application app = new Application();
        _taskTray = new TaskTray();
        app.Run();
    }
}

If you add our TaskTray class into this new project (making sure to add a Using statement for System.Windows), and fire it up we will get our NotifyIcon as before and it looks like we’re all done! Or are we… 🙂

What? Where Did My App Go?

If you decide you want to show a Window from one of your menu items, such as a configuration window, you’ll immediately notice that as soon as the user or application closes that window then your application will immediately quit!

The reason for this is down to the default behaviour of the WPF Application object. The Application object keeps track of all of the Windows opened (as well as a “special” MainWindow which is automatically set to the first Window that is created inside the Application) and when the last window closes, it terminates the application. This default behaviour makes sense for a “normal” application, because most of the time we WANT it to shutdown properly when all the windows are closed; but in our scenario it’s a huge pain in the ****!

The Fix

Our immediate reaction might be to create a “dummy” Window in our bootstrapper and keep it hidden somehow; but this is the same “hack” as the one I disliked from the WinForms version, so we really want to avoid doing that.

Luckily, we can override this behaviour using the ShutdownMode property on our Application object. We can tell it to either terminate only when the MainWindow window closes, or only shutdown when we explicitly tell it to (which is what we want for our application). This changes our bootstrap class to the following:

class BootStrap
{
    static TaskTray _taskTray;

    [STAThread]
    static void Main()
    {
        Application app = new Application();
        app.ShutdownMode = ShutdownMode.OnExplicitShutdown;
        _taskTray = new TaskTray();
        app.Run();
    }
}

We then need to make sure we call Application.Shutdown when we want to quit, which we can do from our Exit menu option:

this.exitToolStripMenuItem.Click += (s, e) => 
    { 
        Application.Current.Shutdown(); 
    };

You can grab the code below:

WpfNotifyIconTest.zip

Posted in Hotwire, WinForms, WPF.

Tagged with , , , , , .


Windows 7 Build 7022 Works With XDDM!

I’ve just installed the naughty leaked Build 7022 version of Windows 7 on my Dell Latitude X1, and it seems that it doesn’t suffer from the XDDM problems that build 7000 did 🙂

With build 7000, the Intel 915 XDDM Graphics Driver required me to drop the hardware acceleration right down to prevent it from hanging, but build 7022 just works out of the box.

I’m not suggesting people go out and grab naughty builds of Win7, but the fact that this problem has been fixed at all is good news for anyone that’s stuck on XDDM drivers.

Posted in Rambling.

Tagged with , , .