I’ve been playing around with .chm files today (that’s Compiled HTML Help to you and me), and I ran across a few annoying issues when launching the help file using Process.Start().

One of the members of IConsoleTab you have to implement for an Add-In is GetHelp(). The WHS Console runs whatever is in this method when the user clicks the Help button in the top right of the console window.


I was doing this:

public bool GetHelp()
	Process.Start(Path.Combine(Application.StartupPath, "DiskManagement.chm"););
	return true;

The problem here is two-fold.

  1. The user can click on the Help button multiple times, and launch multiple instances of my help file.
  2. If the WHS Console instance gets closed while there are still help processes lying around (if the Console is opened on the server, for example), those help processes don’t get cleaned up and the next launch of the console can show some odd behaviour.

After digging around Microsoft’s WHS code (thanks, Reflector!), I’ve found that there’s a better way to do things:

public bool GetHelp()
	Help.ShowHelp(consoleTabControl, Path.Combine(Application.StartupPath, "DiskManagement.chm"));
	return true;

The consoleTabControl is my Add-In’s main tab.

The Help class is in System.Windows.Forms, so you’ve most likely got a reference to it already. You’re passing the same .chm file path, but now the help instance is tied to a specific control. This means:

  1. The user can’t accidentally click on the Console and have the help form disappear behind everything.
  2. If the user clicks the Help button multiple times, the same instance of the help file is returned – no duplication.
  3. When the HomeServerConsole.exe process closes, so too does your help instance (if it’s still open).

Overall, much cleaner.

posted on Tuesday, December 01, 2009 3:17 PM | Filed Under [ Windows Home Server Development ]


Site Sections

Recent Posts


Post Categories

WHS Add-In Tutorial

WHS Blogs

WHS Development