Cue Cards

The Buggy Parts

When using the secondary windows's auto-size feature, the topic is often displayed with scroll bars when it does not need them, or displayed with the last line chopped off. Clearly, the algorithm used to determine the height of the window has not been thoroughly tested. This bug has no workaround that I've been able to find.

When you show your cue card, you might notice that the last line of the last paragraph is separated from the rest of the paragraph more than it should be. I was able to work around this by adding an empty line at the bottom of each topic. The drawback is that the window now has too much white space (or in this case, yellow space) at the bottom. To center the paragraphs better, I had to also insert a blank line at the top of each topic.

For some reason, the last topic in the help file (actually, the last topic in the RTF file used to generate the help file) used a style other than what I assigned to it. As a result, all cue cards were indented .2 inches from the left, except that last one. As a workaround, I had to add a dummy (empty) topic to the end of the RTF file.

One problem that became immediately apparent is that calling the WinHelp API to show a cue card moved the focus to the cue card. We really want the focus to stay with the application, so the user doesn't have to continually click or alt-tab to return there. There are several ways to do this. One way is to have the help file return the focus to the application. This can be done using API calls from the help file, but it presupposes that the application is running and can be found. I took the coward's way out - set the focus back to the app using VB's SetFocus method. This turned out to have another drawback.

When you call WinHelp the very first time, it takes it a few seconds to start up and display the cue card. If you put the SetFocus call immediately after the WinHelp call, the focus is returned before WinHelp is finished starting, so the help window then grabs the focus back when it does finish.

I first added a DoEvents call between the WinHelp and SetFocus calls, but this had little effect. I was finally able to get it to work by calling WinHelp twice (it appears that the second WinHelp call is queued until WinHelp finishes starting) when I first show the cue cards. The second call uses the HELP_FORCEFILE parameter, which forces WinHelp to make sure it has the right file open but otherwise does nothing. If anyone can find a cleaner way of doing this, I'd like to know about it.

This problem is more bizarre than the first ones. The secondary window we're using contains a system box and a close button in its title bar. If the user closes the cue card with these buttons, the application can't tell (at least in VB - there are ways to find out in C by monitoring messages). However, here's the kinky part - once the user closes the cue card window this way, there appears to be no way to get it to restart short of exiting and restarting the application. Turning it off, then on, from the menu has no effect - it stays off.

Thus began my quest to eliminate the close button and system box from the cue card's title bar. It turns out to be easy by using WinHelp macros to call API routines, plus we can turn off the minimize and maximize buttons too! Windows 95 help has a new feature where you can assign a "topic entry macro" to a window class. By assigning the following macros to our secondary window class, they will run whenever the secondary window is used:

SetWindowLong (GetActiveWindow(),-16,0x14840000)

This call will remove the entire title bar and all of its contents, but only if there is no caption for the secondary window (which is why we didn't set one, earlier). If you want to keep the title bar so the user can move the window, replace the hex value with 0x14C40000. If you also want a caption in the title bar, add this macro after the previous ones:

SetWindowText (GetActiveWindow(),` Cue Cards')

Copyright © 2009 by Dana Cline
Last Updated  Monday, April 06, 2009
Website hosted by 1and1