<GMT> Reference Manual: User Interface
|<Index >||<Introduction to the harmony functions>||<General Harmony Functions>|
|<F.A.Q.'s>||<GMT language reference index>|
|<Fuzzy Functions>||<Analysis Functions>||<Acoustical Functions>|
|<Visualisation Functions>||<File Management>||<Psychological Functions>|
The GMT Cockpit
Functions and procedures covered in this chapter:
The GMT user interface consists of standard windows components, called in by the calls to the Win32Api. We have kept it compact and very simple. There are no special visual features. The size of the cockpit window has been kept as minimal as possible, to accomodate the small displays typical on subnotebook windows computers. (640 x 480 pixels). Obviously, if users have larger displays, they can work more comfortably with all the user-dialogs and extra windows GMT may and can generate. User interface components implemented in the cockpit window are:
Only a limited number of these components are available in the cockpit window:
First of all we have a maximum of 64 check boxes in our cockpit allowing for 64 user selectable tasks. These are prepared by filling the Task() structures with the appropriate parameters and code pointers. Most often this will be done by reading data from an ascii file, specific to the application or composition. Procedure code to handle this should be called from or in your own init_myapp function. This procedure also should fill all the required paramaters that are part of the (global) structure app. (cfr. GMT_TYPE.BI). This function should return %True (1) if all setup conditionins for running your application are fullfilled. In all other cases it should return %False. This way users still have a chance to add more items from the menu, until the conditions for running your application become fullfilled.
Then, there are two rows of maximum 12 buttons: A first column of 12 are normally used as toggle buttons (switches), a second colums as one-shots. Properties and behaviour of these buttons are prepared by filling the respective ButnSW() and ButnOS() structures appropriately. If you want to wipe the default contents and functions for these oneshots and switches, you can call the dll procedures ClearCockpitSwitches and ClearCockpitOneShots. The declaration for these macros is:
Below these buttons we can have a maximum of 2 general purpose sliders. Their properties reside in Slider().
Finally, to the right of the two rows of buttons, we can have a maximum of 18 up/down controlls. Their properties reside in the structure UDCtrl().
Apart from these typical windows components, the user can use or remap the keyboard to suit the application. Therefore, we provide specific procedures and structures for handling the function keys (48 key possibilities:
Note that on purpose, we do not allow remapping of the tab, up/down, enter, pageUp, PageDown etc... keys, since these are most often rerouted such as to serve as typical mouse alternatives in windows applications. It is strongly advized not to change this behavior.
For each task , an extra user interface can be build on demand by clicking the right mouse button on an activated task. This will only work for tasks that are active and selected. Information pertaining to these auxiliary windows and dialogs should reside in TaskEX() structures, which can be created on the fly. These extra user interface windows can be closed either in the normal way by clicking them, or by clicking with the right mouse button on the (non-active) task whereto they are associated. In the example left, you see two such interface windows with each a set of 8 sliders, here used to control midi volumes in real time within the application.
User interface components that are not used in a particular application, will not be displayed in the cockpit. The UpdateCockpit procedure handles this during finalization of the interface. For instance: if the user did not select both a midi-in and midi outport, the midi thru button will not appear in the cockpit.
|To homepage dr.Godfried-Willem RAES||<GMT>||e-mail remarks to author|