Gallery

Apps versus solutions

Posted on 4 Mar 2009 at 11:04

Simon Jones asserts that "solution" isn't a dirty word, and finds some powerful code-optimisation tools.

Any grown-up application has to have its own help text, copious quantities of text that hardly anyone will ever read but some poor schmuck has to write anyway. An application's help text will nowadays be contained in a CHM file (a compiled help file), which is a horrible thing to construct. There are tools to help with this chore but they cost an arm and a leg, require a first-rate wrangler to operate, and still can't disguise the fact that a CHM file usually gets delivered with the application's executable file as part of the installation kit, whether that's a setup.exe or an MSI file. That in turn means that the help text has to be written before the application can be delivered, and it can't easily be changed afterwards without releasing a new build of the application. So, for an application that's destined to be used within a single company, why not employ a "wiki" to deliver the help text instead of a CHM file? A wiki, as anyone who's ever used Wikipedia will know, is a set of interlinked web pages that can be added to and edited by its readers (wiki is the Hawaiian word for "quick" and was first used in this context by Ward Cunningham in 1994). SharePoint 3 can ride to the rescue once again, because creating a wiki in SharePoint is a doddle.

From its Site Actions menu, you choose Create and then Wiki Page Library. Now give your wiki a name and description, and you're away. You're offered two sample pages for free and these tell you how to edit, link and manage your wiki. You can use rich text, pictures and tables, and to create a link from one page to another is simply a matter of typing the second page's name surrounded by double square brackets . Whenever you read a wiki page in SharePoint the links between pages show up in blue with underlines, just like normal web links, but if the link points to a page that's yet to be created, that underline is dashed rather than solid and clicking on it will create the page and put you straight into editing mode so you can add content to it. For help text the idea would be to keep the amount of text on any one page small, but to have lots of links from each page to other pages that tell you more, which speeds up access because people don't have to wade through lots of irrelevant information to find the nugget they're looking for.

In Visual Studio applications, every control or form can have a Help Requested event that's triggered whenever the user presses F1, and while this is usually handled by fetching the text from a CHM file, there's nothing to stop you using it to display a wiki page instead, and each form (or even individual controls within a form) can have its own page. The application I've been writing for 15 months has its own internal browser window, and we use that to show the wiki help pages: if someone presses F1 and the browser can't find a specific wiki page for that form, the application detects the resulting "404 - Page Not Found" error and redirects the browser to the main help page, but it simultaneously sends an email telling me which page was requested, so I know that I need to write it soon! We chose to restrict editing of the wiki help pages to a few of the most knowledgeable users, but you could equally leave them open for anyone to edit. By default, SharePoint wikis track all changes, so you can easily restore earlier versions of a page if it's badly edited by introducing erroneous or irrelevant information.

Useful tools

Whether I'm writing applications or solutions (with or without the bunny ears), I normally employ Microsoft's Visual Studio. This is a good development environment, with lots of built-in tools, but some of those tools are a little over-simplified. For example, its built-in bitmap and icon editors are relatively easy to use, but leave a lot to be desired in terms of function. For instance, you can't use more than 256 colours, and while the icon editor does support transparent pixels these must only be either on or off, with no alpha channel that would provide you with 256 different levels of transparency. Bitmaps can't employ transparency at all, leaving you to designate an unusual colour such as magenta as the transparent colour for the controls you use on your forms, if they support such a concept at all; if they don't, you'll have to resort to kludgy code like this: