  |
GoFiler Legato Script Reference
Legato v 1.5b Application v 5.24b
|
| Table of Contents | < < Previous | Next >> |
Chapter Nine — Dialog Functions (continued)
A custom dialog consists of two main components: a template or design (resource) and the supporting code to control the behaviors of the dialog. This is unlike message boxes or common dialogs whose resource and underlying code is managed by the operating system and the script engine. Custom dialogs allow the programmer to design unique dialogs to suit needs specific to his or her application. However, the functionality of that dialog, from adjusting the contents and states of controls to retrieving input data and validating it, is the responsibility of the programmer.
A dialog box consists of two or three basic components depending on whether it is a basic or a property sheet style dialog:
The caption area (also known as the Windows non-client area) is an optional area that can contain a title (caption) and various system menu items. In the above example, the context help is enabled and the close box appears. The second part is the dialog page area which in turn contains controls. For a basic dialog, the page area will contain all controls and there is a single container window.
For a property sheet style dialog, there are multiple pages controlled by tabs:
The caption is the same, however, as shown above. There can be multiple pages, accessed by selecting the tabs. The OK and Cancel buttons do not belong to any one page, which is a significant difference between basic dialogs and property sheets. They belong to the property sheet container and therefore are not easily accessible. The tab text is the caption for the specific page.
The sizes of the dialog and its controls are determined by the dialog resource. For basic dialogs, the dimensions are as specified by the resource while for property sheets, the dimensions specify the size of the inside area of the page with the frame adjusting to the size of the largest page.
Controls are normally composed of a series of “common controls” or window classes specifically designed for Windows applications. Below is a sample of some of the controls:
Static controls can be text legends, lines, and bitmaps. List boxes have various options to show a series of sorted or unsorted data. Sliders act like small scrollbars. Combo boxes come in various styles with the above showing a drop down list and a drop down list with edit. Lastly, there are check boxes shown above.
The appearance of a dialog depends on a number of factors: the version of Windows, the theme selected by the user, possible third-party modifications, whether the dialog is basic or a property sheet, the settings in the dialog resource, and finally what the programmer changes during the dialog load process.
Since Legato dialogs are based upon Windows dialogs, Legato employs defined terms and control names used by other Windows development platforms. Certain predefined items are exactly the same and the resource script (“.rc” file) format follows the Windows resource conventions and can be opened and edited by a number of common applications, such as Microsoft Visual Studio.
The Windows SDK can be referenced for further information on many of the underlying concepts and defined styles as discussed here and employed within the Legato scripting environment.
9.3.4 Modal versus Modeless
As explained in section 9.1, there are two types of dialog box: modal and modeless. While common dialogs and message boxes can only be modal, custom dialogs can be either. A modal dialog box requires the user to supply information or cancel the dialog box before allowing the application to continue. A modeless dialog box allows the user to supply information and return to the previous task without closing the dialog box. Modal dialog boxes are simpler to manage than modeless dialog boxes because they are created, perform their task, and are destroyed by calling a single function.
Modal dialogs are the primary method of a user entering or selecting information for a specific task or function. They are opened, they allow the user to interact with their controls, and then they close. While the modal dialog is open, all other script processing essentially stops until the user completes or abandons the operation. When creating the modal dialog box, the system makes it the active window. Neither the user nor the script can make another window within the script active until the modal dialog box is closed.
In contrast, modeless dialogs allow the user to interact with the dialog and other parts or windows in the application simultaneously. The modeless dialog does not have to be closed in order for script execution to continue. Modeless dialogs include edit windows and progress windows.
Under Legato version 1.x, custom independent modeless dialogs are not supported.
A script typically creates a dialog box by using the DialogBox function to create a modal dialog. This function loads the dialog box template(s) from a resource file and creates a pop-up window that matches the template’s specifications. By supplying an array of templates to the DialogBox function, Legato will automatically treat the dialog as a property sheet style dialog allowing for multiple tabs.
In Windows, dialog boxes (and for that matter, all windows) receive a series of “messages” instructing the application to perform certain tasks or handle certain events. These can include information about what the user has clicked, typed, or selected, for example. By default, all dialog procedures are automatically processed through the script engine. The message loop associated with Windows modal or modeless dialog is not exposed to the programmer. Windows messages can be accessed before script processing, but this is an advanced feature. The user has the option to write event handling procedures to perform select tasks while the script engine handles Windows messages for irrelevant or unimportant events. For more information, see section 9.5 — The Dialog Resource.
| Table of Contents | < < Previous | Next >> |
© 2012-2024 Novaworks, LLC. All rights reserved worldwide. Unauthorized use, duplication or transmission prohibited by law. Portions of the software are protected by US Patents 10,095,672, 10,706,221 and 11,210,456. GoFiler™ and Legato™ are trademarks of Novaworks, LLC. EDGAR® is a federally registered trademark of the U.S. Securities and Exchange Commission. Novaworks is not affiliated with or approved by the U.S. Securities and Exchange Commission. All other trademarks are property of their respective owners. Use of the features specified in this language are subject to terms, conditions and limitations of the Software License Agreement.