Home - Contact Info - Articles
- Files - Links - Adventures - Other Stuff
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
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:
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
Last Updated Monday, April 06, 2009
Website hosted by 1and1