By specifying menu configurations within the application rc file we provide the ability for extensions to include their own menu additions. When combined with the dynamic linking ability this means that new C functions can be written complete with GUI and menu items. These can then be "wrapped up" into a package suitable for distribution to other users.
Not all menus within our programs are specified within the configuration file, but typically the main menu is. Theoretically other menus (such as the gap4 contig editor ones) could be defined in this manner too.
An important concept in the menu code is menu states. At any time a menu item or a menu button can be either enabled or disabled (greyed out). Certain actions require a subset of the menu items to be enabled or disabled. Actions can be split into menu state changes that enable menu items and those that disable them. If an action needs to both enable and disable then two menu state changes should be applied. Menu states are specified as bit patterns with one bit per action.
For example in gap4 we have several enable states and several disable states.
Note that not all bits are used in the enable and disable settings. This is purely to simplify the numbering for the user. For example bits 2 and 3 have the same meaning for both the enable set and the disable set.
Bit 0 is always the startup setting. If a menu item does not have this bit set then it is disabled, otherwise it is enabled.
Bit 1 is always used by the busy mode. Busy mode disables items that have bit 1 set in the disable settings. When busy mode is turned off the menu settings revert to their initial state (prior to busy mode being enabled) and so no enable bit is necessary.
The other bits defined are application dependent. In this case bits 2 and 3 define whether the database opened and whether it contains data.