Copyright: © 1995, Paul Arnote. All Rights Reserved.


Using WinAPI Calls With WinHelp: Part II
Click the right mouse button anywhere in WinHelp's client screen to select topics from the floating menu.

 Using WinAPI Calls With WinHelp: Part II

Most authors of Help files at one time or another want to do something beyond the extensive built-in capabilities of Window Help. Usually, they turn to add-in DLLs to provide the additional functionality they are seeking. And granted, this is necessary in most cases simply because there is no easy way to achieve the results they are seeking.

But, what many Help authors overlook is something that they already have at their disposal — the functions that are, themselves, responsible for controlling and running Windows itself.

Registered users of MiniHelp Plus v3.21 and higher already know of some Windows API calls that can be used to extend the basic functionality of the Help files they write. I provided that information in the Help file Undocumented Help A To Z that came in the MiniHelp Plus Utility Disk they received for registering MiniHelp Plus. Since that time, I have explored other WinAPI function calls that would aid in extending WinHelp. That is what I am presenting here...additional WinAPI function calls that can easily be employed as “custom WinHelp macros.”

It wasn't until I was playing around with creating custom DLLs for Windows Help (something I have been trying to learn over the last few months) that I discovered this solution to some of the shortcomings of WinHelp. It dawned on me that some of what I was trying to write into a custom add-in DLL for Windows Help should be directly available from Windows itself, since most of Windows behavior is controled by three DLLs, KRNL386.EXE, USER.EXE, and GDI.EXE.

Once I unraveled the mystery of changing the WinHelp title bar text, I thought that possibly there are other WinAPI functions that I could similary register with WinHelp as custom macros, without having to leap through DLL hoops. That is how I got started exploring...nay, discovering...what I am presenting to you in this file.

Certainly, these “custom macros” could be implemented in an add-in WinHelp DLL and could probably be made easier to use as a result. But using this method — using what you already have — does have its clear advantages.

First of all, there is no programming skill involved or needed. Anyone, programmer or non-programmer, can make use of these function calls pretty much at will.

Secondly, the Help author who makes use of these function calls has no additional files to distribute with their Help files. Every user that views the Help file already has the DLLs in which these functions reside, simply because they are running Windows and these are the core files necessary for the operation of Windows.

I am certain that there are more WinAPI function calls that can be used with WinHelp as custom macros. As they are discovered by me (or revealed to me by one of you out there), I will produce Part III of using WinAPI calls with WinHelp.

Mind you, I make no guarantee of reliability or usability. But I see no reason why anyone writing Windows Help files shouldn't be able to make use of these functions for their own use. Just please use these ‘custom macros’ cautiously and with respect. By using these functions, you are stepping into the Windows programmer’s world, and as any Windows programmer knows, it is very easy to make Windows crash or to wreak havoc on a user's system with only a few misplaced parameters.

And you should keep in your mind that which virtually every Windows programmer already knows: an ill-behaved app is an app that is seldom, if ever, used. You want people to use your “app,” in this case your Help file. If you follow my instructions specifically, yours will be a well-behaved app that will see frequent use among your audience. Follow my instructions specifically, and you should have no worries that you will crash Windows or wreak havoc on another user’s system.

Paul Arnote

Table Of Contents


WritePrivateProfileString Test

Click Here to test the WritePrivateProfileString function.

Click Here to view TEST5.INI.


Using SetWindowText To Change The Title Bar Text: Main Help Window
Click the right mouse button anywhere in WinHelp's client screen to select topics from the floating menu.

 Changing The Title Bar Text:

 Main Help Window

Certainly, there have been times when writing a Windows Help file that I yearned for the ability to change the title bar text of the main Help window to more accurately reflect the topic that I was discussing. In fact, it is because of this very shortcoming of Windows Help — the lack of ability to easily change the title bar text — that I am such a ferverent advocate of defining non-scrolling regions in my Help files. These were available and easy to do to accomplish much the same thing, but in a different way. And both accomplish the same result: to keep the Help file reader oriented to his/her place within the intricately webbed Help file.

To accomplish this you must first define the following in the HPJ [CONFIG] section (.hpjconfig for MiniHelp Plus users):

 RegisterRoutine(`user.exe', `SetWindowText', `US')

To execute the new “macro”:

 SetWindowText(hwndApp,  `text to display on title bar')

Note that hwndContext will not work with this; only hwndApp!

See how easy that is! With just the right information, what was once impossible is now possible. Examples of this macro are presented all throughout this Help file, as each topic displayed in the main Help window sets the title bar text to reflect the current topic matter.

 See Also:

Changing The Title Bar Text: Secondary Help Windows

Table Of Contents


hwndContext
hwndContext: the handle to the currently displayed Help topic. An internal WinHelp variable available for use to all Help authors.


hwndApp
hwndApp: the handle to the current instance of the WinHelp application. An internal WinHelp variable available for use to all Help authors.


Changing The Title Bar Text of Secondary Help Windows.
Click the right mouse button anywhere in WinHelp's client screen to select topics from the floating menu.

 Changing The Title Bar Text:

 Secondary Help Windows

To change the title bar text of a secondary Help window, you must work a little harder. First, you must register both the FindWindow and SetWindowText Windows API functions in the HPJ’s [CONFIG] section. Here are their declarations (MiniHelp Plus users use .hpjconfig):

 RR(`user.exe', `FindWindow', `U=SS')

 RR(`user.exe', `SetWindowText', `US')

Now, define your secondary window in the [WINDOWS] section of the HPJ file (MiniHelp Plus users use .hpjwin):

 second = "a",(237,100,585,600), 0, (255,255,255), (192,192,192) ,0

You must give your secondary window a caption when you define it. It needn't be a fancy caption. Notice that in the example above (which, by the way, is the exact definition of the secondary window of this Help file), I have created the secondary window with the caption of “a.” But you can call it whatever you want. Just be sure that in each secondary window you define (Windows Help will only allow the definition of five (5) secondary windows), you give each secondary window its own, unique caption.

Next, execute the macro as follows:

 SetWindowText(FindWindow(`MS_WINTOPIC_SECONDARY',  `old text of window caption'),  `text of new window caption')

The old text of window caption is the text you specified in the caption portion of the window definition statement in the [WINDOWS] section of the HPJ file when you defined the window.

The `text of new window caption' is the text you want to display on the window’s title bar.

Typically, I would execute this as a topic macro (MiniHelp Plus users use .tmacro) to change the secondary window’s title bar text when the topic is displayed in a secondary window. However, do not preclude the use of this macro from a hot spot (MiniHelp Plus users use .mlink) or from the [CONFIG] section of the HPJ file (MiniHelp Plus users use .hpjconfig).

By executing this macro upon entering a topic, the same secondary window can be used to display several different types of data, each with its own caption on the title bar. And, if you couple this macro with the standard WinHelp macro PositionWindow, there is a virtually unlimited number of secondary windows available for your use, and not just the five (5) that WinHelp limits you to.

 	Click on the graphic at left to see a demonstration.

 See Also:

Changing The Title Bar Text: Main Help Windows

Table Of Contents


Modifying the Secondary Window's System Menu
Click the right mouse button anywhere in WinHelp's client screen to select topics from the floating menu.

 Modifying The System Menu:

 Controlling Secondary Help Windows

From time to time, you may want to prevent the user from closing secondary Help windows via the system menu. Instead, you might want to take control of the exit procedure so certain things that need to be cleaned up are taken care of before the window is closed.

For example, say you were displaying, playing, and controlling the playback of a Video for Windows AVI clip via hot spots linked to the multimedia library (MMSYSTEM.DLL). Closing a secondary window that the video clip might be playing in via the secondary window’s system menu might leave no way to close the video file and remove its image from the user’s screen.

Therefore, it becomes advantageous to make it impossible to exit the secondary window via the secondary window’s system menu. Instead, it is much better if the user exits the window via a hot spot you have defined in order to close the video clip before closing the secondary window. This way, the video clip’s image is removed from the user’s screen and the AVI file is properly closed.

Accomplishing this is actually easier to do than you might think. Simply place the following commands in the [CONFIG] section of your HPJ file. (MiniHelp Plus users: use the .hpjconfig command from your MiniHelp Plus source file):

 RR(`user.exe', `FindWindow', `U=SS')

 RR(`user.exe', `SetClassWord', `Uiu')

 SetClassWord(FindWindow(`MS_WINTOPIC_SECONDARY',`a'), -26, 0x0200)

 CAUTION! Since this removes the Close menu item from the secondary window’s system menu, you MUST make sure to create a hot spot that executes the WinHelp CloseWindow(`window-name') macro. Otherwise, the user will have NO quickly apparent way to clear the window from the screen and the only way to do so is to invoke the Task Manager and select End Task to exit the entire Help file.

Here’s what’s going on. FindWindow is returning the hwnd (handle) to the secondary window belonging to the class MS_WINTOPIC_SECONDARY and the title bar caption of “a.” Using SetClassWord, we are modifying the GCW_STYLE (-26) class field offset to the class style CS_NOCLOSE (0x0200). For you non-programmers, all we are doing is changing the style of the window to disallow closing it from the system menu.

 Click on the graphic at left to see an example of a secondary window with its system menu modified in this manner. NOTE: this example does not do what it says it does, due to inconsistent behavior. You may still click on the graphic and read the text, but the custom macro execution of removing  Close from the system menu of the secondary window has been disabled. If you please get this figured out, I WANT TO KNOW!!!!

 See Also:

Table Of Contents


Graphic

 Click on the  RED  buttons to select your topic.


Sample of Changing Secondary Window Title Bar Text
When I entered this topic, I used a topic macro to set the window text to Changing Title Bar Text.

 Now, click on the button at left to toggle the title bar text.

The above is a good example of using a macro hot spot to execute the SetWindowText macro. Here is the macro I used to toggle the title bar text:

 IfThenElse(IsMark(`t1'), `DeleteMark(`t1');SetWindowText(FindWindow(`MS_WINTOPIC_SECONDARY', `Changing Title Bar Text'), `Changed!')', `SaveMark(`t1');SetWindowText(FindWindow(`MS_WINTOPIC_SECONDARY', `Changed!'), `Changing Title Bar Text')')

In MiniHelp Plus source code format:

 .mlink IfThenElse(IsMark(`t1'), `DeleteMark(`t1');SetWindowText(FindWindow(`MS_WINTOPIC_SECONDARY', `Changing Title Bar Text'), `Changed!')', `SaveMark(`t1');SetWindowText(FindWindow(`MS_WINTOPIC_SECONDARY', `Changed!'), `Changing Title Bar Text')')^"bigbut.bmp"

Of course, this is all typed on one line, but is broken up here to fit into the Help window. In the topic macro, where I first set the text of this secondary window, I saved a text marker called ‘t1’ and use the macro in the hot spot to check for the presence of that text marker. If it exists, it is deleted and the title bar text altered. Now, the second time you click on the macro hot spot, the text marker does not exist so it is saved again and the title bar text changed back to the first instance.

Walk through the macro implementation and notice how the title bar text in each implementation of FindWindow must be relative to the current title bar text.

Usually, though, your implementation of the SetWindowText macro will be much simpler than the complex example above. I include it here as a demonstration of what you can do with it.


Removing Close From the System Menu of a Secondary Window

This is an example of using SetClassWord(FindWindow(`MS_WINTOPIC_SECONDARY', `a'), -26, 0x0200) to remove the Close menu item from the system menu of this secondary window.

Open the system menu and you will notice that the menu item Close is no longer present. To exit this window, you must select the “Close Window” button hot spot.

As far as I can ascertain, this macro ** ONLY ** works if executed from the [CONFIG] section of the HPJ file. The window behavior must be altered before it is ever shown. If you attempt to execute this as a topic macro, the changes do not take effect until the second time the window is displayed. If you attempt to execute this macro from a macro hot spot, the window’s system menu is not altered at all.


WriteProfileString
Click the right mouse button anywhere in WinHelp's client screen to select topics from the floating menu.

 Using WriteProfileString

 To Modify WIN.INI

A lot of you might ask why would you want to modify WIN.INI from a Help file. Actually, I can think of several reasons, some of which I’ll share with you.

First, suppose you wrote a Help file telling users how to “tune up” Windows, which would mean explaining some of the various settings in WIN.INI. Now, you could either simply tell them what to do, or you could do it for them. You could set up various macro hot spots that the user could use to select the modifications he/she wanted to make to WIN.INI. You would then instruct the user to exit and restart Windows to make the changes take effect. Or you could define a hot spot that would also exit and restart Windows for them.

To exit and restart Windows, define the following as a macro. This may be used either as a topic macro or as a macro hot spot. Using it in the [CONFIG] section of the HPJ file would make no sense, since the macro would execute when the Help file loads—every time it loads. You could, however, create a button on the button bar that executes this macro.

 RR(`user.exe', `ExitWindows', `Uu')

 ExitWindows(0x42, 0) causes Windows to restart.

 ExitWindows(0x43, 0) causes the system to be rebooted.

This will not work if the user has an application running that refuses to terminate.

The second reason I can think of (yes, I actually had a MiniHelp Plus user ask me this one) is when you want to control the size of the main Help window after the main Help window has been closed. This particular user had created a wonderful little Help file called GO! It simply was a small “utility” that launched all sorts of applications—a launching utility, if you will, using Windows Help. The contents of the Help file were displayed in a secondary window so the size of GO! could be kept to a minimum without the overhead of the menu and button bars.

He had wanted to eliminate the “flash” of the main Help window when the Help file initially loaded, and was actually on the right path before abandoning the idea and querying me for assistance. What he had figured out was that he could create the main Help window the same size as the secondary window and in the same positon. Problem was, he had no way to reset the size of the main Help window once he closed it. Thus, the next Help file he opened was displayed in the tiny, small size of the main Help window he had closed. WIN.INI records the size and position of the main Help window each time WinHelp is closed and opens the next session of Help with the main Help window set to the size it had recorded.

What he needed was a way to “remove” or change the information stored in WIN.INI regarding the size of the main Help window. This is easily facilitated by manipulating the data in WIN.INI, passing in new data for the size of the main Help window with WriteProfileString.

Before we address how to use WriteProfileString, we first need to know what sorts of information about WinHelp is stored in WIN.INI. Below is a table of available parameters and data:

M_WindowPosition	[x.tl, y.tl, x.br, y.br, Max(0 or 1)]
H_WindowPosition	[x.tl, y.tl, x.br, y.br, Max(0 or 1)]
A_WindowPosition	[x.tl, y.tl, x.br, y.br, Max(0 or 1)]
C_WindowPosition	[x.tl, y.tl, x.br, y.br, Max(0 or 1)]
Colors	NONE
JumpColor	(R, G, B)
IFJumpColor	(R, G, B)
PopupColor	(R, G, B)
IFPopupColor	(R, G, B)
MacroColor	(R, G, B)
LogoStart	(R, G, B)
LogoEnd	(R, G, B)
SeqTopicKeys	value (0 or 1)
In the table above, M_WindowPosition is the position of the main Help Window, H_WindowPosition is the position of the History window, A_WindowPosition is the position of the Annotate dialog box, and C_WindowPosition is the position of the Copy dialog box. The set of five numbers following each window positioning statement are, in order, the window’s screen coordinates relating to the top left horizontal, top left vertical, bottom right horizontal, and bottom right vertical edges of the screen. The Max parameter specifies whether the window is maximized (1) or not maximized (0). These sizing parameters must be enclosed in opening and closing brackets.

 Colors=NONE is a special setting that allows you to override author defined colors for the background of the scrolling and non-scrolling regions of the screen, as well as text colors. This is useful if your display is incapable of generating certain color combinations or if certain color combinations render the Help file unusable on your system (i.e., monochrome monitors). This command instructs WinHelp to use the Control Panel defaults for foreground and background colors (except for hot spot colors, which are controlled by the next five settings). This entry must be manually placed in WIN.INI, since there is no other provision for placing it there.

The next five entries deal with defining the colors used for textual hot spots on the screen. Simply pass a RGB (Red, Green, Blue) color combination to these entries, enclosed in parenthesis. The acceptable values for each of the color intensities is 0 to 255. If you are unsure of what each entry stands for, refer to the quick reference of terms available by selecting the Quik Ref button on the button bar.

 LogoStart and Logo End define the colors of WinHelp’s native screen background if you launch WinHelp without a file. Both of these entries accept an RGB color combination enclosed in parenthesis as its parameter.

 SeqTopicKeys is a relatively undocumented entry that allows the user to single-step through all the topics in a Help file (including popups). The value for this entry is one (1) to be enabled, or zero (0) to disable. With the entry enabled, pressing Ctrl+Shift+Right Arrow moves to the next topic, while Ctrl+Shift+Home moves to the first topic in the file. To move backwards through the file, however, you must use the Back button on the button bar, since Ctrl+Shift+Left Arrow doesn't do anything. One minorly annoying bug with this command is that when press the Ctrl+Shift+Right Arrow keys on the last topic, WinHelp displays the message “Help Topic Does Not Exist” not once, but twice.

Now that we have covered the [Windows Help] section of WIN.INI and you now know what each entry is for, let’s see how to alter them directly with WriteProfileSting.

First, we need to use RegisterRoutine to register the function for use as a WinHelp macro. The format is as follows (MiniHelp Plus users use .hpjconfig):

 RR(`krnl386.exe', `WriteProfileString', `SSS')

Once this is done, you can use this macro from a macro hot spot, as a topic macro, or as a macro that executes when your Help file is loaded (placed in the [CONFIG] section of your HPJ file). Execute the macro as follows:

 WriteProfileString(`WIN.INI Section', `Section Entry', `Entry Value')

 WriteProfileString(`Windows Help', `M_WindowPosition', `[0, 0, 600, 400, 0]')

There are several things to note here. First, you can change any of the WIN.INI entries that control WinHelp by passing in the appropriate Section Entry and Entry Value.

Second, you can effect changes in any section of WIN.INI, not just the [Windows Help] section (remember my first example as to why you might want to alter the contents of WIN.INI?). For this reason, you MUST use EXTREME CAUTION when messing around with another user’s WIN.INI file. One ill-executed WriteProfileString macro could completely wipe out an entire section of a user’s WIN.INI file, possibly rendering it impossible to restart Windows again without reinstalling at least the basic version of WIN.INI from the Windows installation disks.

Thirdly, in the above example where I reset the sizing and positioning of the main Help window, I really don't have to pass any value at all, if I so choose. You must remember that if WinHelp doesn't find an entry value, it uses its own built in defaults. So, I could have just as easily written the example as follows:

 WriteProfileString(`Windows Help', `M_WindowPosition', `')

where the entry values are an empty string (only the opening and closing single quotation marks with nothing between them). Thus, I effectively remove the size and position information I do not want and allow WinHelp to use its own defaults the next time WinHelp is opened.

The fourth point is to remember that Windows keeps a copy of WIN.INI cached in memory, to speed access. If I want to flush the contents of WIN.INI from memory, all I have to do is pass empty strings for each of the three macro parameters. Thus, the next time Windows needs to reference data stored in WIN.INI, it won't find the old version cached in memory and will read the new version—complete with my modifications—into memory. Using this method, it is possible to make some changes to WIN.INI take effect immediately without having to restart Windows.

 See Also:

WritePrivateProfileString

GetProfileInt

GetPrivateProfileInt

Table Of Contents


WritePrivateProfileString
Click the right mouse button anywhere in WinHelp's client screen to select topics from the floating menu.

 Using WritePrivateProfileString

 To Modify INI Files

There may be an occassion when you might want to alter the contents of an INI file, other than WIN.INI. Say, for example, you want/need to make changes to the INI file that belongs to Control Panel (CONTROL.INI). Or perhaps you need to make changes to Program Manager (PROGMAN.INI) or File Manager (WINFILE.INI). Or maybe you need to make changes to any other INI file that resides on your system. Any of this can easily be accomplished by registering WritePrivateProfileString as a custom WinHelp macro.

To register this for use as a WinHelp macro, supply the following in the [CONFIG] section of the HPJ file (MiniHelp Plus users use .hpjconfig):

 RR(`krnl386.exe', `WritePrivateProfileString', `SSSS')

Once you have done this, you can execute the new macro either from the HPJ file (to execute when the Help file is loaded), as a topic macro, or from a macro hot spot. Execute the macro as follows:

 WritePrivateProfileString(`Section', `Entry', `Entry Value', `INI Filename')

 WritePrivateProfileString(`Test', `Test1', `This is a sample of writing to an INI file', `testini.ini')

Some of the same things we must keep in mind about manipulating WIN.INI also apply to private INI files, with a few more cautions. First, you must be cautious with the parameters you pass to a private INI file, just as you would be with WIN.INI. An errant entry value could really mess up a program’s private INI file.

Second, you must think twice before passing an empty string as a entry value parameter. Most programs do provide their own defaults for the variables stored in INI files, but not all. You must be certain that the program the INI file belongs to substitutes default values for those values in the INI file you delete.

Third, just as a copy of WIN.INI is cached in the memory, so are copies of the most recently called INI files in order to speed access. If you want to effect changes to an INI file, some of the changes could be made to take effect immediately, without having to exit the program and restarting it. All we simply do is pass an empty string in the first three parameters of WritePrivateProfileString, specifying only the INI filename. This forces the INI file to be flushed from memory and the next time the data is needed, Windows will read the file from disk, complete with all your new additions. Keep in mind, however, that some programs only read certain data at the time they are loaded, so any changes you make will not take effect until you exit and restart the program.

 Sample:

Click on the “Hand & Pencil” graphic to write to a private INI file, called TESTINI.INI. Click on the “Telescope” graphic to view the TESTINI.INI file. Note that clicking on the telescope graphic before clicking on the hand & pencil graphic will do nothing; you must click on the hand & pencil graphic first.

 See Also:

WriteProfileString

GetProfileInt

GetPrivateProfileInt

Table Of Contents


MiniHelp Plus v3.21: Order Today!
Click the right mouse button anywhere in WinHelp's client screen to select topics from the floating menu.

 MiniHelp Plus v3.21

 The Complete Help Writer’s Authoring Utility

 MiniHelp Plus v3.21 is the Complete Help Writer’s Authoring Utility that makes creating Windows Help files as easy...if not easier than...learning to use a word processor. Requires no high dollar word processor. Uses what every Windows user already has to create a full-featured authoring environment. In fact, this entire Help file was created using MiniHelp Plus v3.21.

 MiniHelp Plus v3.21 allows you to create your Help file by way of a specially scripted ASCII text file in your favorite ASCII text editor. The scripting commands are easy to use and easy to remember. This is a full featured Help authoring utility. Nothing is disabled, like in some shareware Help authoring utilities.

Here is a list of the features of MiniHelp Plus v3.21:

•  Easy to use “point-n-click” user interface.

•  Fully configurable...allows the user to define the default Help Compiler, ASCII Text Editor, Graphics Editor, and Hot Spot Editor to use in Help file construction.

•  One click Build & Test option...allows the user to convert the ASCII text file to RTF, run the Help Compiler, view the Help Compiler error file, and view the Help file—all with one click of the mouse.

•  Automatic generation of Help Project file and context-sensitive Help header file.

•  View/edit your Help file’s graphic files by selecting the View Graphics button on the user interface.

•  Status bar echoes your last action.

•  Always On Top function.

•  Sports the popular 3D look.

•  And much, much more...

This popular shareware package is available for $30 registration. When you register, you get a special MiniHelp Plus utility disk that contains Help files detailing the documented and undocumented Help macros (and then some!), a special Help file providing hints & tips on using MiniHelp Plus, a special set of utilities that allow you to peer into any Help file’s internal file system, special add-in WinHelp DLLs, and more.

Click on the graphic at left to display the order form for MiniHelp Plus. From there, you can print out the order form by clicking on the Print button on the button bar.


Order Form
Click the right mouse button anywhere in WinHelp's client screen to select topics from the floating menu.

 Order Form

 Name:___________________________________________________________________

 Address:________________________________________________________________

 City/State/ZIP:_________________________________________________________

 Where Did You Obtain Your Copy of WINAPI2.HLP?__________________________

 ________________________________________________________________________

 If from America Online, please state your screen name. Otherwise, please state your E-Mail address.

 Suggestions/Comments:___________________________________________________

 ________________________________________________________________________

Thank you for ordering your copy of MiniHelp Plus v3.21. Please send $30 cash/check/money order to:

 Paul Arnote

 1208 Randolph

 Leavenworth, KS  66048

For an additional $20, you can order your copy of EW256BMP.DLL, a WinHelp add-in DLL that allows you to display 256 color bitmaps in your Help files, as well as extract files stored in WinHelp’s baggage file systems and delete those files when you are finished with them. Please mark which item(s) you are ordering. Please allow 2-4 weeks for shipping.

 _____ Order  MiniHelp Plus v3.21  ONLY

Send $30 cash/check/money order.

MiniHelp Plus v3.21 will be sent to you on 3½" DSHD disks, unless

otherwise noted.

 _____ Order EW256BMP.DLL  ONLY

Send $20 cash/check/money order.

EW256BMP.DLL will be sent to you on a 3½" DSHD disk, unless otherwise

noted.

 _____ Order  BOTH  EW256BMP.DLL and  MiniHelp Plus v3.21

Send $50 cash/check/money order.

All programs will be sent to you on 3½" DSHD disks, unless otherwise

noted.


Report Form
Click the right mouse button anywhere in WinHelp's client screen to select topics from the floating menu.

 WinAPI For WinHelp Report Form

 Name:__________________________________________________________________

 Address:________________________________________________________________

 City/State/ZIP:_________________________________________________________

 Internet E-Mail Address:________________________________________________

Include below a brief description of how this new custom macro works (i.e., the RegisterRoutine declaration, the macro format and parameters, and other pertinent data) so I can test your new discovery.  Please attatch print outs of your HPJ file, the complete topic text of the topic where the macro is executed, and any other supporting files.

 ________________________________________________________________________

 ________________________________________________________________________

 ________________________________________________________________________

 ________________________________________________________________________

 ________________________________________________________________________

 ________________________________________________________________________

 ________________________________________________________________________

 ________________________________________________________________________

 ________________________________________________________________________

 ________________________________________________________________________

Thank you for reporting your newly discovered API function call that can be used by WinHelp as a custom macro. Please mail this reporting form to:

 Paul Arnote

 1208 Randolph

 Leavenworth, KS  66048

If you are the first to report a newly discovered API function call that can be registered for use by WinHelp as a custom macro, I will include it in the next update, More WinAPI Function Calls For WinHelp: Part III along with your name and E-Mail address.


GetProfileInt
Click the right mouse button anywhere in WinHelp's client screen to select topics from the floating menu.

 Using GetProfileInt To Read

 Integer Values From WIN.INI

In the Windows programming API, there is a variable of the type BOOL, which simply returns a TRUE (1) or FALSE (0) value. Many of the programming functions in Windows are of the BOOL type, meaning they either return TRUE if it succeeds, or FALSE if it fails. Many other functions in the Windows programming API are defined as the type “int,” simply meaning it returns a number, usually either a zero or non-zero value.

However to WinHelp, BOOL and the variable type “int” (meaning integer) are the same. Values other than 0 or 1 seem to have little meaning to WinHelp itself (although you can pass values other than 0 or 1 as parameters to macros that require them). In specific, I am referring to how WinHelp interprets values that are passed to the conditional macros IfThen and IfThenElse.

When checking for a condition, WinHelp only checks to see if the specified value is TRUE or FALSE. If it is TRUE, or non-zero, WinHelp further processes the conditional macro. However, if the value is FALSE, or zero, WinHelp either processes the “Else” portion of the IfThenElse macro, or does nothing in the case of the IfThen macro.

Any of the Windows API functions which return a variable type of BOOL or int can, therefore in theory, be registered as custom macros that check whether a condition exists on the user’s system. Note, however, that we must be able to register all the variables to the function with WinHelp. Functions that use special structures, pointers to structures, pointers to PROCS, or pointers to other variable types for which we have no clear variable type defined in WinHelp, cannot be used simply because there is no way to declare the variable type with WinHelp. For a list of parameter types that can be passed to a custom macro, refer to Parameter Specs in the quick reference table by selecting the Quik Ref button on the button bar.

One place where we can check whether or not a certain condition exists is in WIN.INI. We can register the function GetProfileInt for use as a custom WinHelp macro, since its function is cast as the type unsigned integer.

To register this function with WinHelp, place the following in the [CONFIG] section of your HPJ file (MiniHelp Plus users use .hpjconfig):

 RR(`krnl386.exe', `GetProfileInt', `u=SSi')

The “u” is the return value. The “S” parameters are respectively, the section and entry names in WIN.INI to look for. The “i” parameter is the default value to use if the entry cannot be found. Typically, the default value will be zero.

Execute this macro either as a topic macro, from a macro hot spot, or when the Help file is loaded by placing it in the [CONFIG] section of the HPJ file.

 IfThenElse(GetProfileInt(`windows', `ScreenSaveActive', 0), `PI(`', `ACTIVE')', `PI(`', `NOACTIVE')')

The above example would check to see if the user had a screen saver active, and if so, would display the message contained in the topic ACTIVE in a popup window on the screen. If a screen saver was not active on the user’s system, then the message contained in the topic NOACTIVE would be displayed instead.

In and of itself, this is not a very useful example (just one I could locate quickly), but demonstrates what can be done with a little imagination.

 Sample:

 Click on the button at left to see GetProfileInt at work. This is the exact implementation of the example I gave you above.

 See Also:

WriteProfileString

WritePrivateProfileString

GetPrivateProfileInt

Table Of Contents


Active
Screen Saver is active.


NoActive
Screen Saver is inactive.


GetPrivateProfileInt
Click the right mouse button anywhere in WinHelp's client screen to select topics from the floating menu.

 Using GetPrivateProfileInt To Read

 Integer Values From INI Files

Just as we can use GetProfileInt to read integer values from WIN.INI, we can use GetPrivateProfileInt to read integer values from other INI files.

Say you have written a program that has two different display modes: one for expert users and another, simpler mode for novices. When your program loads, it checks an entry in your program’s private INI file for the presence of and ExpertMode setting. If this setting is “1”, the expert mode of your program is displayed. Similary, your Help file could read this setting to determine which topics to display in your Help file. Quite a tedious, but real, undertaking.

Another possibility arises when you want to read an integer value stored in PROGMAN.INI, WINFILE.INI, CONTROL.INI, or any other INI file.

Just like its counterpart,GetPrivateProfileIntis used to test a condition to pass along to one of WinHelp’s conditional macros, IfThen or IfThenElse.

First, register the function as a WinHelp macro in the [CONFIG] section of your HPJ file as follows (MiniHelp Plus users use .hpjconfig):

 RR(`krnl386.exe', `GetPrivateProfileInt', `u=SSiS')

The “u” is the return value. The next two “S” parameters are respectively, the section and entry names in the INI file to look for. The “i” parameter is the default value to use if the entry cannot be found. Typically, the default value will be zero. The last “S” parameter is the name of the INI file to look in.

Next, execute this macro either as a topic macro, from a macro hot spot, or when the Help file is loaded by placing it in the [CONFIG] section of the HPJ file.

 IfThenElse(GetPrivateProfileInt(`Screen Saver.Stars', `PWProtected', 0, `control.ini'), `PI(`', `PROTECTED')', `PI(`', `NOPROTECTED')')

The above example would check the Screen Saver.Stars entry in CONTROL.INI to see if it was password protected. If it is, the contents of the topic PROTECTED is displayed in a popup window. If it is not protected, the contents of the topic NOPROTECTED is displayed in a popup window instead.

Once again, this in and of itself is not a very useful example but is here to simply give you an idea of what you can do with this custom macro.

 Sample:

 Click on the button at left to see GetPrivateProfileInt at work. This is the exact implementation of the example I gave you above.

 See Also:

WriteProfileString

WritePrivateProfileString

GetProfileInt

Table Of Contents


Protected
The Starfield Screen Saver  is  password protected.


NoProtected
The Starfield Screen Saver is not password protected.


Other WinAPI Possibilities...
Click the right mouse button anywhere in WinHelp's client screen to select topics from the floating menu.

 Other Possible WinAPI Functions

 For Use As Custom Macros

Consider this a call for input—your input. Certainly there are other WinAPI calls that might be able to be registered as custom WinHelp macros. Explore and check out some of the other possibilities I have listed below, or see if you can find some I might have missed. Also, don your sleuthing cap and check out the More WinHelp Mysteries... topic to see if you can figure out what some of the undocumented “discoveries” I found in an ASCII dump of WinHelp are and how to use them.

Use the WinAPI For WinHelp Report Form and share your discovery with everyone else. With “official” documentation on WinHelp severely lacking from Microsoft, it is up to all of us to take up the slack. Send them to me at the address on the reporting form and I will compile all that work into Using WinAPI Calls With WinHelp: Part III so everyone can learn. I will include your name and E-Mail address with the topic so interested users can contact you and share their information with you. What I hope to ultimately create is sort of like a network of users who have a keen interest in WinHelp and expanding its functionality.

Where To Look

I truly wish I could just include a copy of the C language header file for Windows for you to look through. However, doing so would violate the licensing and non-disclosure agreements to which I am held through the licensing of my development packages. What I can do, however, is present you with informational data which tells you how to use the assorted function calls, as I have done in this Help file. If you possess this file, this should be the first—and best—place to search for other WinAPI function calls to use as custom WinHelp macros.

Other places to look would be in books, especially books that list undocumented Windows API functions. Any of the books, however, that describe and show how to utilize the Windows functions can be considered a very, very good source.

Another place to look is in individual DLLs. Search through their header files and documentation. Is there anything there that might make itself useful as a custom WinHelp macro? One good (and fairly well documented) example is in MMSYSTEM.DLL, the multimedia interface for Windows. Browsing through its header file and documentation leads us almost immediately to the sndPlaySound function that allows us to play .WAV files in Help files, and the mciSendString function that allows us to control multimedia devices (CD-ROM, MIDI files, AVI files, etc.) from WinHelp. Certainly other DLLs exist from which we can “borrow” additional WinHelp functionality. (Caution:  Just be sure that the DLLs you are looking in can be distributed along with the Help file that uses them without violating copyright laws and licensing agreements. Some DLLs require that you are a licensed user of the program to which they belong in order to legally possess and use them. Others allow distribution of some DLLs but not others in a program package. If in doubt, save yourself potential legal problems and  check with the copyright owner!)

A Brief List Of Other Possibilites

Below is a brief list of some other WinAPI functions that might be able to be used as custom WinHelp macros. While this list is far from complete, it does serve to steer you in the proper direction and give you a clue for what to look for. Each possibility listed below will include the C header file declaration, a sample RegisterRoutine entry, and a few brief words about usage or limitations.

Note that these are all untested with WinHelp but in theory, should work. If you are successful at using any of the following (or anything else you might discover), I would be interested in seeing how you put it to use. Where you see two RegisterRoutine declarations, the first is if you want to check the return value in one of WinHelp’s conditional values and the second is if you simply want to execute the macro without testing a condition.

I certainly do hope to hear from a lot of you regarding new “discoveries” of other WinAPI functions for use as custom WinHelp macros.

USER.EXE: Possible Custom WinHelp Macros

 void ShowOwnedPopups(hwnd, fShow)

 RR(`user.exe', `ShowOwnedPopups', `Ui')

 What it does: shows or hides all popup windows owned by the specified window.

 Parameters: hwnd should equal hwndApp. fshow will equal one if you want all popup windows owned by WinHelp to be displayed, or zero if you want them all to be hidden.

 BOOL IsWindowVisible(hwnd)

 RR(`user.exe', `IsWindowVisible', `i=U') to test a condition

 What it does: determines the visibility state of the specified window. Return is zero if the WS_VISIBLE style flag is not set, or 1 if it is. Will return 1 (TRUE) even if the window with WS_VISIBLE style flag is set but is covered up by other windows on the screen.

 Parameters: “i” represents the return value (zero if false, 1 if true). hwnd is the handle of the window.

 BOOL ShowWindow(hwnd, nCmdShow)

 RR(`user.exe', `ShowWindow', `i=Ui') to test a condition.

 RR(`user.exe', `ShowWindow', `Ui') to execute directly.

 What it does: sets the specified window’s visibility state. Returns non-zero if the window was previously visible and zero if it was previously hidden.

 Parameters: “i” represents the return value (zero if false, non-zero if true). hwnd is the handle of the window to display. nCmdShow is the display value and may be one of the following:

0	Hide window and pass activation to another window.

1	Activates and displays window in normal state.

2	Activate window and show window as icon.

3	Activate window and show maximized.

4	Show window in most recent size and state.

Currently active window retains focus.

5	Activate window and show in current state.

6	Show window as an icon. Activates current

top level window in system’s list.

7	Show window as an icon. Currently active

window retains the focus.

8	Show window in normal state. Currently active

window retains the focus.

9	Activates and displays window in normal state.

 BOOL BringWindowToTop(hwnd)

 RR(`user.exe', `BringWindowToTop', `i=U') to test a condition.

 RR(`user.exe', `BringWindowToTop', `U') to execute directly.

 What it does: brings the specified window to the top of a stack of overlapping windows. Returns non-zero if successfule, zero if unsuccessful.

 Parameters: “i” specifies the return value. hwnd (U) is the handle of the window you want to bring to the top of the stack.

 void CloseWindow(hwnd)

 RR(`user.exe', `CloseWindow', `U')

 What it does: minimizes the specified window but does not destroy it. It is likely that this will not work since WinHelp will confuse it with its own built in CloseWindow macro. Instead, refer to the ShowWindow API function.

 Parameter: hwnd is the handle of the specified window you want to minimize.

 BOOL EnableHardwareInput(fEnableState)

 RR(`user.exe', `EnableHardwareInput', `i=i') to test a condition.

 RR(`user.exe', `EnableHardwareInput', `i') to execute directly.

 What it does: enables or disables keyboard and mouse input. Return value is non-zero if queing of input was previously enabled, otherwise it’s zero.

 Parameters: The first “i” is the return value (zero for FALSE, non-zero for TRUE). The second “i” is either zero, for false, to disable mouse and keyboard input, or non-zero, or one for true, to enable mouse and keyboard input.

 BOOL EnableScrollBar(hwnd, nScrollType, uScrollFlag)

 RR(`user.exe', `EnableScrollBar', `i=Uiu') to test a condition.

 RR(`user.exe', `EnableScrollBar', `Uiu')

 What it does: enables or disables one or both of the arrows of a scroll bar. Returns non-zero if action is carried out or zero if action is not carried out.

 Parameters: The first “i” is the return value (zero for FALSE, non-zero for TRUE). hwnd (U) is the handle of the window (hwndApp for the main Help window). The second “i” (nScrollType) specifies which scroll bar. Enter ‘3’ for both scroll bars, ‘0’ for the horizontal scrollbar, and ‘1’ for the vertical scroll bar. uScrollFlag (u) is the value that specifies the enabling/disabling value. Enter 0x000 to enable both, 0x001 to disable the left arrow of a horizontal scrollbar or the up arrow of a vertical scrollbar, 0x002 to disable the right arrow of a horizontal scrollbar or the up arrow of a vertical scrollbar, and 0x003 to disable both arrows.

 HWND GetActiveWindow(void)

 RR(`user.exe', `GetActiveWindow', `U=')

 What it does: retrieves the window handle (hwnd) of the currently active window. Might be able to be used in place of FindWindow API function.

 Parameters: You will only be interested in the return value. The function itself accepts no parameters. Thus, you would use it like GetActiveWindow(), just as you would the Print() or Exit() macros.

 HWND GetCapture(void)

 RR(`user.exe', `GetCapture', `U=')

 What it does: returns the handle (hwnd) of the window that currently has the mouse capture. Might be able to use this in place of the FindWindow API function.

 Parameters: You will only be interested in the return value. The function itself accepts no parameters. Thus, you would use it like GetCapture(), just as you would the Print() or Exit() macros.

 HWND GetFocus(void)

 RR(`user.exe', `GetFocus', `U=')

 What it does: returns the handle (hwnd) of the window that currently has the input focus. Might be able to use this instead of the FindWindow API function.

 Parameters: You will only be interested in the return value. The function itself accepts no parameters. Thus, you would use it like GetFocus(), just as you would the Print() or Exit() macros.

 HMENU GetMenu(hwnd)

 RR(`user.exe', `GetMenu', `U=U')

 What it does: returns the handle (HMENU) to the menu of the specified window (hwnd).

 Parameters: The first “U” (HMENU) is the return value. The second “U” (hwnd) is the handle to the window that owns the menu you want to access. You will most likely use this as a variable to retrieve the handle of the menu, much like we used FindWindow to retrieve the handle of a window.

 WORD SetClassWord(hwnd, nIndex, wNewWord)

 LONG SetClassLong(hwnd, nIndex, nVal)

 RR(`user.exe', `SetClassWord', `u=Uiu') to test a condition.

 RR(`user.exe', `SetClassWord', `UiU') to execute directly.

 RR(`user.exe', `SetClassLong', `I=UiI') to test a condition.

 RR(`user.exe', `SetClassLong', `UiI') to execute directly.

 What they do: These two functions are presented together since they work very much alike by changing the window class of a window. These are of particular interest to me, since I intended to include them in this Help file. They can be used to disable Close on the system menu of a secondary window by specifying the second value -26 and the last value 0x0200. However, at the last minute I discovered that its behavior was not consistent. Sometimes it would work, sometimes it would not.

 Click on the button at left if you want to see the topic text I had intended to include about these functions. If you do get this one figured out and get it to behave consistently, I especially want to know what you did to get it to perform consistently.

KRNL386.EXE: Possible Custom WinHelp Macros  Note that in most instances, krnl286.exe also works.

 int GetPrivateProfileString(lpszSection, lpszEntryName, lpszDefaultString, lpszBuffer, nBufferSize, lpszIniFilename)

 int GetProfileString(lpszSection, lpszEntryName, lpszDefaultString, lpszBubber, nBufferSize)

 RR(`krnl386.exe', `GetPrivateProfileString', `i=SSSiS')

 RR(`krnl386.exe', `GetProfileString', `i=SSSi')

 What it does: The return value of this function is the number of bytes copied into buffer, excluding the terminating null character. You will only use this to test a condition, such as only to see if an entry exists. There is no way to retrieve what the value of the entry is. If a value exists, the return value will be non-zero (TRUE). If a value does not exist, the return value will be zero (FALSE). Use GetProfileString to check for the presence of values in WIN.INI. Use GetPrivateProfileString to check for the presence of values in all other INI files.

 Possible Implementation: your implementation of this custom macro might look something like this:

 IfThen(GetPrivateProfileString(`Colors', `Windows Default', `', `', 0, `control.ini'), `PI(`',`COLORS')')

 UINT WinExec(lpszCmdLine, uCmdShow)

 RR(`krnl386.exe', `WinExec', `Su')

 What it does: this function executes the program specified in the lpszCmdLine parameter. The “u” (uCmdShow) value is the value that specifies how the program is initially shown and is the same as the parameters for ShowWindow (see above). You might want to use this one as a replacement for the WinHelp ExecProgram macro, since there are more ways to specify how to start the program up.

Unfortunately, there isn't a whole lot of possibilities evident in krnl386.exe. During my look-through of this module, these and the ones I detailed in this Help file are the only ones I spied that I thought might be useful as custom WinHelp macros.

And gdi.exe doesn't look promising at all, since this Windows core DLL is responsible for drawing on the screen.

But don't let this stop you from exploring what you consider to be promising functions for use as a custom macro. I might have missed something. Sometimes, not having a need for something can cause you to miss that something that’s right under your nose that at some later point might be useful.


 Quick Reference Guide

Parameter Specs

WinHelp Internal Variables

[Windows Help] WIN.INI Settings

Sources For More Information

More WinHelp Mysteries...

Copyright © 1995, Paul Arnote.  All Rights Reserved


Parameter Specs
Macro Parameter Specs

Below is a listing of the proper parameter specs to use when declaring a macro variable with RegisterRoutine.

Character	Data Type	Equiv. Windows Data Type
u	Unsigned short integer	UINT, WORD, WPARAM
U	Unsigned long integer	DWORD, HWND, HMENU, HDC
i	Signed short integer	BOOL, int, short
I	Signed long integer	LONG, LPARAM, LRESULT
s	Near pointer to a null terminated string	PSTR, NPSTR
S	Far pointer to a null terminated string	LPSTR,LPCSTR
v	Void (mean no type; only used with return values)	None. Equivalent to C void data type.


WinHelp Internal Variables

Below is a listing of the WinHelp internal variable available to Help authors and the proper parameter specs to use when with them when declaring a macro variable with RegisterRoutine.

Variable	Format	Description
hwndApp	U	Handle to the main help window
hwndContext	U	Handle to the currently active Help window
qchPath	S	Fully qualified path to the currently open Help file
qError	S	Pointer to a WinHelp error structure
lTopicNo	U	Current topic number
hfs	U	Handle to the file system for the currently open Help file
coForeground	U	Current foreground color in the active Help window
coBackground	U	Current background color in the active Help window


[Windows Help] WIN.INI Settings

Below is a listing of the known settings in the [Windows Help] section of WIN.INI.

Setting	What It Does
M_WindowPosition	Retains the last size and display state values for the main Help window.
H_WindowPosition	Retains the last size and display state values for the Help History window.
A_WindowPosition	Retains the last size and display state values for the Annotation dialog box.
C_WindowPosition	Retains the last size and display state values for the Copy dialog box.
Colors	If equal to NONE, WinHelp ignores author defined colors & uses system colors.
JumpColor	Defines the color to display jump hot spots in. (R, G, B) format.
IFJumpColor	Defines the color to display inter-file jump hot spots in. (R, G, B) format.
PopupColor	Defines the color to display popup hot spots in. (R, G, B) format.
IFPopupColor	Defines the color to display inter-file popup hot spots in. (R, G, B) format.
MacroColor	Defines the color to display macro hot spots in. (R, G, B) format.
LogoStart	Defines the color of logo start in upper left corner. (R, G, B) format.
LogoEnd	Defines the color of logo end in lower right corner. (R, G, B) format.
SeqTopicKeys	If active, value is 1 (one). If inactive, either missing, no value, or 0 (zero).


Sources For More Information

Below is a listing of sources you might want to consult as you attempt to discover more WinAPI function calls and to learn more about Windows Help v3.1.

 The Developer’s Guide To WINHELP.EXE, Harnessing the Windows™ Help Engine, by Jim Mischel. Published by John Wiley & Sons, Inc. $39.95 for book only, $49.95 for book with companion disk (recommended).

 Windows 3.1 SDK (Software Development Kit), by Microsoft. Available with most programming packages. Of particular interest is the file WIN31WH.HLP which is the Help file listing all the documented Windows 3.1 function calls.

 ANY Windows 3.1 Programming reference book. Popular publishers include SAMS Publishing, Abacus Software, The Waite Group, and Microsoft. Of particular interest might be Undocumented Windows by Andrew Schulman, David Maxey, and Matt Pietrek. Published by Addison-Wesley. Through reverse engineering, these men have uncovered 250 undocumented functions and data structures for Windows 3.0 and 3.1. Price is $39.95 and comes with a companion disk.

 ANY documentation for the Windows API add-ons (i.e., MMSYSTEM.DLL for multimedia, the Microsoft TAPI, etc.) you can find. Generally, since these DLLs can be distributed royalty-free, they can usually accompany your Help file without any legal snafus. Most of these add-ons have Help files documenting their usage.

 ANY documentation on any DLL used by any Windows program. Caution is the keyword here to avoid infringing on copyrights and license agreements. Always check with the DLL’s copyright holder/author to get permission before distributing any “private” DLL.


Copyright & License Agreement
This file is  Copyright © 1995, Paul Arnote. All Rights Reserved.  No warranties, guarantees, or assurances are made concerning the information provided herein. By installing and using this file, the user  agrees that the author of this file is not responsible for any loss of information or productivity and that the author of this file is not responsible for damages resulting from the use or misuse of the information presented.  This file is presented as is, and the user uses this file and the information contained within at his or her own risk.

 This file may be freely distributed and no charge may be levied for it, except as otherwise noted. Shareware distributors may include this file on a disk containing other shareware software, so long as the total cost of the  disk does not exceed $10 or the cost of producing/distributing such a disk, whichever is higher.

 The information contained in this file may not be reproduced via any means, current or future. Individual users may print out portions of this file for their own private use, however. Inclusion of the content of this file in  any book, magazine, or other medium is prohibited without the expressed written consent of its author, Paul Arnote.


More WinHelp Mysteries...
Click the right mouse button anywhere in WinHelp's client screen to select topics from the floating menu.

 More WinHelp Mysteries...

Recently, I was poking around in WinHelp. I performed a sort of ASCII dump of the WINHELP.EXE and HCP.EXE programs (using a program from the now defunct Compute! magazine called SuperSnooper), and discovered some undocumented commands/variables/INI file settings (we’ll just refer to this as “stuff”).

Perhaps one of you out there know the answer to one or more of the mysterious “stuff” discovered in the ASCII dump of WINHELP.EXE and HCP.EXE. If you do, please use the WinAPI For WinHelp Report Form to let me know what you find out. To date, I have had no luck figuring these out.

 defaulttopic This is found in the dump of WINHELP.EXE but not HCP.EXE. Could this, perhaps, be another possible entry for WIN.INI or WINHELP.INI? Or is this just another internal WinHelp variable? If so, are we able to access it and pass it values?

 IgnoreVersion This, too, is found only in the dump of WINHELP.EXE. I am fairly certain that this is a possible WIN.INI entry, but cannot figure out how to implement it. Let me know what you find out. Perhaps I'm reaching, but if this works, does this mean we might be able to view Viewer .mvb files in Windows Help? Or does this exist to allow us to view Help files intended for prior versions of Windows?

 DisplayTopicOnce Like the two previous discoveries, I found this only in the dump of WINHELP.EXE. This, too, I suspect, may be another possible WIN.INI entry but I do not know what value to pass to it. Is the value strictly numerical, textual, or both? Or is the value a hash value of a particular topic context string? If so, does that mean we can have several such entries in WIN.INI, one for each topic of a different Help file we want to only display once? Or is this an INI entry that belongs in WINHELP.INI?

 ShellAbout I do know what this is, but am unsure of how to implement it. Found in WINHELP.EXE, this displays the About dialog box that is common between virtually all the native apps that ship with Windows. If you can figure out what parameters are passed to this function in SHELL.DLL, you could use the framework of the About dialog box to display your custom text.

 CbtComm Supposedly, CBT (Computer Based Training) support has been removed from WinHelp v3.1. So, what is this? Is this a leftover from previous versions of WinHelp? Is this a CBT hook built in to WinHelp v3.1? If so, where is it implemented—in WIN.INI or WINHELP.INI? What values are passed to it?

 LowMemory Found in the ASCII dump of WINHELP.EXE, this entry appears listed between CbtComm and SeqTopicKeys, the latter of which we discussed in the WriteProfileString topic. What is its function? Where is it implemented? What does it do? What values are passed to it?

 Club %d %d gives %d keyphrases for an estimated savings of %ld bytes. This one, found in HCP.EXE, really isn't a setting but a display message. I've never seen it displayed. When is it displayed?

Certainly, as you can see, several things in WinHelp remain undocumented mysteries. My not being able to come up with answers for this “stuff” hasn't been for a lack of trying. I do tend to get around and ask lots of questions. Now I'm asking you to educate the rest of us if you know anything about these things I've listed above. Then all of us will be on equal footing and Microsoft’s lack of documentation won’t matter any more since we will have done it ourselves.


Created with MiniHelp Plus v3.21
This Help file was created with

 MiniHelp Plus v3.21

 Written by Paul Arnote

 Copyright © 1994.  All Rights Reserved.

 Derived from the original MiniHelp that appeared

 in the January, 1994 issue of Compute Magazine.

 Written by Tom Campbell

 Copyright © 1994.  All Rights Reserved.

If you would like to use MiniHelp Plus v3.21 to create

your Help files, you may obtain your SHAREWARE copy

by either downloading it off of America Online or a

local bulletin board (depending if it has made it there yet).

Or you may write to:

Paul Arnote

1208 Randolph

Leavenworth, Kansas  66048

Send $30.00 to the address above.

Be sure to specify disk size,

density, and program name, as well as your

name & address.  Cash, check or money order.
Please make checks/money orders out to
Paul Arnote.  Registered users

will receive a free Help utility disk, filled with
bitmaps, hot spot graphics, and special
Help DLLs to enhance and add functionality
to your Help file creations.

While this version is not crippled in any way, registration

removes the nag screen that appears when you first start
MiniHelp Plus v3.21.  Please register

your copy if you find it useful and support the shareware concept,

as well as helping to keep me interested enough

to keep improving on this program.

Back To What You Were Doing