Hacker’s Guide to Visual FoxPro
An irreverent look at how Visual FoxPro really works. Tells you the inside scoop on every command, function, property, event and method of Visual FoxPro.
These two functions allow you to toggle on and off a special debugging mode for monitoring the interaction of your application and help files. This can be very useful in ensuring that you provide help for built-in dialogs you include in your application.
SYS( 1023 ) && turn on diagnostic mode
SYS( 1024 ) && return to normal mode
Help can be invoked in a number of ways within an application. For example, F1 can be pressed to bring up help, passing information about the item with focus or the text that is highlighted. Shift+F1 or WhatsThisHelp passes the WhatsThisHelpID of the item clicked on when in WhatsThisHelp Mode. Within the Command Window, a developer can type HELP and the name of the topic for which he wants help. For all of these cases, these two SYS() Functions
allow you to see the information passed to the Help engine.
As we discuss in the HelpContextID section, the ID is a unique address for a help topic in the help file. For controls that you build, the HelpContextID is a property you assign in the Form and Class Designers, but for other built-in elements, like the “Minimize” option on the active window control menu, the ID is already coded for you—one job of these functions is to determine and display that ID for you.
Designed long before Windows became the sole platform for VFP, SET TOPIC
can accept either a numeric or a string argument. Similarly, Windows Help and HTML Help can be invoked passing either a string or a number, accepting either integers (HelpContextIDs) or strings (Help topics) through the same API call. (Internally, FoxPro passes an additional argument to Help to tell it whether to expect a string or an ID integer.) While the Windows Way to do things is to assign every control a HelpContextID, it’s also possible to assign the topic using SET TOPIC
, perhaps in GotFocus and LostFocus. These SYS() Functions
display either the ID or string passed to help. In a remarkable coincidence, this technique works for all of the flavors of help: DBF, WinHelp and HTML Help.
These functions accept no parameters and return the empty string. When diagnostic mode is running, any call to help pops up a Yes/No message box, telling you the information to be passed to the Help engine and allowing you to decide to continue or abandon the operation. Pressing F1 while an object has the focus (or a menu pad is highlighted) displays the HelpContextID for that item. Typing HELP and the thing you want help on offers to pass the string you type to the Help engine. For example, issuing the command HELP TableUpdate passes the string ‘TableUpdate’ to the Help engine. Alternatively, selecting File-New from the menu and pressing F1 displays the HelpContextID (both in decimal and hexadecimal format) sent to the Help engine.
Don’t forget when designing and testing your coverage of HelpContextIDs in your application to cover the built-in dialogs, like GETCP()
and LOCFILE()
, as well as the window and application control menus. In addition, you’ll want to make sure you’ve tested and created help for all of the HelpContextIDs for Windows Common Dialogs or any OCXs your application uses. SYS(1023) can supply you with those HelpContextIDs as well.