The standard way for changing the module-context is to choose the select module menu entry from the Options menu in the user interface. A dialog with a listbox containing all known modules in the current context are shown. Double-clicking a module entry in the listbox sets the current module-context to the selected module and lists all modules that are visible in this module (i.e., its submodules and supermodules.
Figure 5.1: The module-context selection window
In our example, you should get a listbox containing the modules System, Employees, and Managers (see Figure 5.1). Now double-click the listbox-entry Managers. As a result the module-context of the CBserver is set to the module Managers. As the Managers module has got no nested modules, there are no additional modules displayed in the listbox (i.e., all modules that are visible in the System module are also visible in the Managers module.
Alternatively you can specify the module-context using the load model-Operation and placing a {$set module=MODNAME} inline-command in the very first line of a SML-file. MODNAME stands for the name of the module in which you wish to define the content of the SML-file. Please note that only one inline-command is allowed within one SML-file. Specifying module-contexts using inline commands is a facility for automatically loading SML-definitions of large applications which are spread over different modules - without requiring the user to select the select module-function from the CBworkbench.
Let's set the module-context to Employees and then TELL the following frame:
Employee with
attribute
name : String
end
The object Employee is now only visible in the module Employees. When you set the module-context to Managers (or System) and try to load the Employee object, you should get an error message from the server stating that the object Employee is not visible in that module-context.