I have been writing Windows help files for nearly 30 years. It’s a very time consuming process to set up and maintain application help files. And just when I think I have a stable, workable system, Microsoft pulls the rug out from underneath me.

With the introduction of Windows Vista in 2006, Microsoft deprecated WinHelp and no longer includes it with the factory images of Windows Vista, Windows 7 and Windows 8.

HTML_help is Microsoft’s replacement for WinHelp. However, the Windows HTML_help viewer is crippled. It will only open CHM help files on a PC, not those stored on an intranet. Instead of content, the viewer displays the absolutely meaningless “Navigation canceled” message:

I have never understood this. An intranet is an internal network, so why in the world would it be considered a security risk to open a file on your own internal network? Apparently, Internet Explorer (tightly integrated into the Windows OS), is not able to discern the difference between the internet and an intranet.

So, I have been sticking with WinHelp as it is freely available for download from Microsoft for Vista, Windows 7 and (surprisingly) Windows 8, with both 32- and 64- bit versions:

Microsoft KB Article 917607

Not until my PC at work was (finally) updated to Windows 7, did I realize that WinHelp is now just as useless as HTML_help. Windows 7 now blocks WinHelp from opening HLP help files stored on an intranet.

Again, WTF? What is the security risk of opening a file on your own internal intranet?

I could not find a trustworthy third party HLP file viewer, so I decided to switch to the CHM help format and seek out a replacement for Microsoft’s HTML_help viewer for intranet applications. After hours of web searching, I eventually found xCHM, a free, open-source, multi-platform, functional replacement for Microsoft’s HTML_help viewer.

Although it doesn’t have all the bells and whistles, xCHM does, at least, open CHM help files stored on an intranet.

In order to utilize xCHM, the help calls in APK had to be rewritten. Logically there are three scenarios:

1. If the program is running from a local drive, the default help handling system is called.
2. If the program is running on an intranet, and xCHM is available, then xCHM is called to display the relevant help topic.
3. If on an intranet, and xCHM is not found, then an error dialog is displayed with a link to web help on rxkinetics.com.

Code snippets

Determine if the program is running locally or via intranet:
function TfrmMain.IsOnLocalDrive(): Boolean;
var
aDrive: string;
begin
aDrive := ExtractFileDrive(Application.ExeName);
if (GetDriveType(PChar(aDrive)) = DRIVE_REMOVABLE) or
(GetDriveType(PChar(aDrive)) = DRIVE_FIXED) then
Result := True
else
Result := False;
end;


Determine which help system is available:
function TfrmMain.LocalHelpAvailable(): integer;
begin
if IsOnLocalDrive then
result := 1
else
begin
if XchmInstalled then
result := 2
else
result := 0;
end;
end;

Intercept the application help call and choose which help system to use:
function TfrmMain.ApplicationEvents1Help(Command: Word; Data: Integer;
var CallHelp: Boolean): Boolean;
var
MyHelpKeyWord : string;
begin
case LocalHelpAvailable of
0: begin
// On network and xchm is *not* installed
CallHelp := False;
frmHelp_Link.ShowModal;
end;
1: CallHelp := True; // Local drive
2: begin
// On network and xchm *is* installed
CallHelp := False;
// Get HelpContext of current active control
MyHelpKeyWord := IntToStr(Screen.ActiveControl.HelpContext);
// If control HelpContext is blank -> Get Parent HelpContext
if MyHelpKeyWord='' then
begin
MyHelpKeyWord := IntToStr(Screen.ActiveControl.Parent.HelpContext);
// If parent is blank and parent is not a form, get form HelpContext
if MyHelpKeyWord='' then
begin
if Screen.ActiveControl.Parent <> Screen.ActiveControl.Owner then
MyHelpKeyWord := IntToStr(Screen.ActiveForm.HelpContext);
// Fallback: if control, parent, and form HelpContext are all blank -> display start up topic
if MyHelpKeyWord='' then
MyHelpKeyWord := '10';
end;
end;
ShellToXchm(MyHelpKeyWord);
end;
end;
end;

Shell out to xCHM:
procedure TfrmMain.ShellToXchm(HelpTopic:string);
var
strParameters : string;
begin
// Create parameter string -- Requires short path name!
strParameters := ' /c ' + HelpTopic + ' ' + GetShortName(PathName) + 'apk.chm';
// Shell out to xCHM
ShellExecute(Application.Handle, 'open', 'xchm.exe', PChar(strParameters), PChar(PathName), SW_SHOW);
end;

Looking back, this has probably been an exercise in futility. It seems as though most pharmacists either don’t know there is a help system built into the program, or they don’t care. Either way, no one has bothered to contact me to report a problem. Why am I not at all surprised?

The lack of Unicode support in the wiki is something that has bugged me for a couple of years. M$ Word is the usual source of these non-standard characters, such things as em- and en-dashes and curly (smart) quotes. If these non-ASCII (non-keyboard) characters were pasted into a topic they would be displayed as garbled nonsense in the viewer and editor.

Display

Editor

This project was written in Delphi 2007 which does not natively support Unicode. I have XE, but I have no desire to go through the hair-pulling, forehead-slapping ordeal of updating all of the components in this project to yet another version of Delphi.

Since it did not support Unicode, the most likely suspect to me was the standard TRichEdit component. So, back in April I purchased the TMS Unicode component package. Well, that didn’t get very far because there was a major bug in the search function. Really, what good is a wiki without a search function? So, I emailed support and they put it on their to-do list. Eventually it got fixed and I updated that component this morning. Unfortunately that didn’t fix anything. So began the dogged pursuit of a fix.

The next suspicious component on the list was the HTML viewer. So, I found an update to the 5 year old open source component on code.google. After removing the old and re-compiling the new, no change.

Still believing it was a component problem, I looked into the database driver as the culprit. I pulled up SQL manager and did a dump of the raw data. It was fine, all the proper Unicode characters were there.

Then I began to believe that it had to be a problem with the variable declaration. All the experts on stack overflow had an opinion on what was the best string type to use for Unicode, and they were all different. So, I systematically changed the variable holding the text to every oddball string type available in Delphi: Utf8String, WideString, ANSIstring, and RawByteString. It didn’t matter, the output was still garbled.

I finally came across the open source Fundamentals code library on SourceForge. Included in that library were various decoder routines for converting character sets and encodings to and from Unicode. A function within it called UTF8StringToUnicodeString was the trick. Finally, it displays Unicode formatted text properly.

clear_display

I hope all you copy-and-pasters appreciate how much fricking work this was. And don’t get me started on what a gawd-awful-piece-of-shit-poor-excuse-for-a-word-processor M$ Word is.

• Word must die
• Word sucks

Today I finally figured out how to increase the size of the lines in the nutritional assessment grid.

I was following Microsoft’s example code to a “T”
How to Set Pen Width and Alignment

But, as is usually the case, the devil is in the details. No one ever gives you the complete story. They give you just enough information to frustrate you. By trial and error I found out why it wasn’t working. I was declaring the Pen object inside the DrawGrid subroutine. For some silly reason, it has to be declared globally. I never would have guessed that.

Anyway, the grid looks much better now: