The Menu Program (Magic xpa 3.x)
A menu module is required to interact with all the running programs of the entire subsystem, such as calling requested programs and closing existing ones, while remaining within the subsystem context. These requirements are best achieved by creating the menu module as a browser-client program.
The menu module usually displays the available options that can be activated. Clicking on a displayed menu option activates the corresponding logic.
Implementing the Menu module as a browser-client program lets you handle the displayed menu options easily and simply respond to the relevant click events that take place on the menu options to activate the corresponding logic.
The Menu Interface
The menu program interface should provide a visual display of the menu options. The elements that represent menu options can be a push button, a hyperlink, static text, or an image.
To easily manipulate the display elements, you should define them first in the HTML control list of the menu system program.
|
Important:
|
In some menu systems you might not want the menu option display elements to be parkable. On the other hand, a browser-client task requires at least one parkable control. To serve this end you may set a parkable virtual field on the form and set its size to be zero, for example:
<INPUT type=text name=”virtual” style=”width: 0px”>)
|
The Menu Logic
The main menu logic responds to menu option activation. Handling menu option activation may vary according to the selected display elements:
-
Push buttons - Use the raise event property of the push button, and handle the raised event as necessary.
-
Static text and hyperlinks are defined in the HTML control list as Hypertext controls. Handle the click event of each control to perform the required operations.
|
Note:
|
When handling a hyperlink click event, the hyperlink HREF attribute should be set as void to prevent the browser from trying to open a URL.
<A name=”option1” href=”Javascript: void(0)”>
|
The Handlers
The relevant events triggered by the displayed menu options should be handled to perform the logic required to execute the expected subsystem thread. Usually such handlers would simply call the top browser task that serves as the starting point of the subsystems threads.
This handler may include logic that must be performed before the actual Call operation that serves as the initialization of the subsystem thread, or after the Call operation that serves as the closing stage of the subsystem thread.
The Transaction
The menu browser task does not usually require modification to the application tables. Furthermore, every transaction opened by a subsystem thread is expected to be an independent transaction.
For these two reasons it is best to set the Transaction mode task property to None. This way the browser task will not open a redundant transaction, and each transaction opened by a called subsystem thread will be independent of the menu task.
