Extending Menu Specifications Across Modules
In some G2 applications, completely defining a menu in one module is inconvenient or impossible. For example, consider a proprietary module that is to be extended by users in ways that cannot be anticipated. The users cannot change the module, because it is proprietary, but they must be able add to its menus, or they will not be able to extend its capabilities conveniently.
To provide for such situations, GMS allows you to extend a menu specification across modules using extensible stubs. There are two template objects for extending your menu specification across modules:
Both of these stubs must be given Names in order for them to be "continued" in another module. When the GMS compiler encounters an unresolved stub, it ignores the stub, just as it would a dangling connection stub. Thus you can use stubs to provide optional hooks for extending menu specifications. A menu specification that uses this technique is called an extensible menu specification.
To create an extensible menu specification:
- Begin the menu specification as you would any GMS menu specification.
- Perform one of these actions:
- Give the stub a unique name.
To continue an extensible menu specification in another module:
- In the module that defines the extension to the specification, perform one of these actions:
- Connect the stub to the first entry to be added by the module.
- Define the rest of the menu as you would in any menu specification.
The menu specification in the second module can again contain a Place Holder or end with a uniquely named Peer Menu Connection Post, which may or may not be continued in a third module, and so on through any number of modules.
Note: This technique works only with Peer Menu Connection Posts: you cannot include an unresolved Submenu Connection Post in a menu specification. The GMS compiler will signal an error if it encounters such a post.
Copyright © 1997 Gensym Corporation, Inc.
