| Oracle Help for Java Developer's Guide | Previous |
Next |
Context sensitive help launches help topics that are associated with some context in the user interface. Typically, help topics are written to describe user interface controls such as menus and dialog boxes. When a user requests help for a user interface control--for example by selecting a Help button--the appropriate topic for that context (control) is displayed.
The following sections describe how to implement context sensitive help using Oracle Help for Java:
Oracle Help for Java provides mechanisms for associating help topics with UI controls, and for launching context sensitive help when the end user presses the F1 key or clicks Help in a right-click context menu. OHJ also provides an API for explicitly requesting that the help topic associated with a component is shown.
Context sensitive help requires that the help content created by the author includes a map file that maps topic IDs to help topics. In a HelpBook a map file is in the OHT file format, in a helpset the map file is in an XML file format discussed in the OHJ File Format Specification.
As the programmer, when calling the Help.showTopic() method or associating help topics with your Java UI controls you must use the topic IDs specified in the author's map file. Thus, you will have to coordinate your efforts with the help author.
If you wish, you may consider defining a set of Java constants in your application code that map to the author defined topic IDs in the map file. When using OHJ methods that require help topic IDs you can use the constant variable names instead of hard-coding an author-defined topic ID. This will allow you to avoid changing your code in several places if the author changes the topic IDs at a later point.
OHJ's CSHManager (Context Sensitive Help Manager) class provides a way of associating help topics with Java UI components and enabling F1 and right-click context sensitive help. The plain Javasoft toolkits (AWT and Swing) do not have a built-in way of associating help topics with components, and thus require an external mechanism like OHJ's CSHManager. The following section will guide you through using the CSHManager to enable context sensitive help.
You should create an instance of the CSHManager class before you begin creating your UI components. The CSHManager constructor takes the Help instance for your application.
| Constructor Detail |
|---|
CSHManager(Help help)
|
If you only have one Book of help content, you may want to use the CSHManager setDefaultBook() method to define it as the default book for context sensitive help. This allows you to go without entering the book parameter when you call the addComponent() method.
| Method Detail |
|---|
setDefaultBook(Book book)
|
If you have more than one book, the default book will only be used for those components for which you have not assigned a specific book. In a multiple book help system, you should, in general, assign specific books to your components.
The addComponent() method is used to associate topic IDs (as defined in the map file) with Java UI components. You will have to call one of the versions of this method for each component that requires context sensitive help.
| Method Detail |
|---|
addComponent(Component component, String topicId)
|
addComponent(Component component, Book book, String topicId)
|
addComponent(Component component, String topicId, boolean needF1Help, boolean needPopupHelp)
|
addComponent(Component component, Book book, String topicId, boolean needF1Help, boolean needPopupHelp)
|
Call the showHelpForComponent() method on the CSHManager when you explicitly want to display the help topic associated with a given component. For example, if you want to launch context-sensitive help in response to a button press, you could call this method in the button's event handler.
| Method Detail |
|---|
showHelpForComponent(Component component)
|
If the user requests help from a non-modal window, the user may switch back and forth between the help requesting window and the displayed help topic (as you would expect).
Unfortunately, in Java, a modal window blocks access to all other windows created by the Java Virtual Machine (except yet another modal window). Thus, if help is requested from a modal window, OHJ must display help in a modal help window.
When help is requested, OHJ determines whether the active window is modal. If it is, then it re-parents the normal OHJ topic windows and the OHJ navigator window into a new modal window. That new window appears in the foreground of the user's display, and the user can interact with it; in fact, they must interact with it if only to close the (modal) help window. Given the coarse implementation of modality in Java, this is the only solution that will work for all of the Java Virtual Machines currently supported by OHJ.
In order for the OHJ workaround for the modal window problem to work, OHJ must be able to track the currently active window. To facilitate this process, you must register each window (Frame or Dialog) that you create with the Help object using the registerClientWindow() method.
| Method Detail |
|---|
registerClientWindow(Window aWindow)
|
unregisterClientWindow() method. It is important to note that failure to unregister Window instances may result in the window not being garbage collected.
| Method Detail |
|---|
unregisterClientWindow(Window aWindow)
|
Previous |
Next |