Module

Module(name [, HELP(fileName)])

[, Synopsis(text₁, text₂, ..., text_m)]
[, Dictionary(T(keyWord₁₁, keyWord₁₂, ..., keyWord_1m), ..., T(keyWord_n1, ..., keyWord_nm))]) 

The InstantView^® interpreter overreads all descriptions about synopsis and dictionary. 
Whenever the SystemObject function ParseLib() reads the InstantView^® code - for the InstantView^® browser - this information will be evaluated.

Windowobjects, that have been defined with InstantView^®, their action lists, all defined variables and statements are always assigned to a module. The statement 'module' defines that all following definitions belong to this module.
Each module generates its own name space for variables, user-defined statements and window objects. There is a pre-defined module called 'GLOBAL'. which makes all included variables, statements and window objects globally visible.

The same applies for the module 'SYSTEM', which is used by the ClassiX^®-Workbench. This module was meant to separate workbench variable and statements from variable and statements of projects that have been edited with workbench. 'SYSTEM' helps, when InstantView^® is applied to itself.
Do not use 'SYSTEM', since its development has been stopped!

Modules define the scope of local InstantView^® variables, statements and window objects. For an overview of InstantView^® element visibility, please click here.  

Module(name[, HELP(fileName)]) : baseModName

[, Synopsis(text₁, text₂, ..., text_m)]
[, Dictionary(T(keyWord₁₁, keyWord₁₂, ..., keyWord_1m), ..., T(keyWord_n1, ..., keyWord_nm))]) 

The new module has been derived from an already defined module. The realized inheritance concept follows the principles of object-orientation: Base module elements are adopted, as long as they have not been overdefined by an element with the same name in the derived module. In detail, this means the following:

Variable

If there is a variable x in the base module, the derived module will contain a variable with this name, too. This inherited variable is just like an explicitly declared variable local - a value change of a further derived modules variable x has no effect on x (see example).
Since variables haven no particular attributes, the variable overdefinition is basically pointless - result would just be another variable x, which is already part of the module anyways.

Statement

Whenever a statement s has been declared in the base module, this statement is also known in the derived module, unless a new variant of s is defined in this module. Inside the new definition - which is often an extension of the old statement - it is possible to refer to the base module statement with the notation

super::s

or call the statement definition in a particular base module on the inheritance path with

     moduleName::s 

With this construction - module name and scope operator :: - the original versions of all directly or indirectly inherited statements are accessible within a statement definition (and only here!) (Example).

Action list

A base module action list will be adopted, too. In a derived module, the reaction to a specific event can be overwritten by simply redefining it there. Instead of the base module action, now the action in the derived module will be triggered. The overwritten statements can only be activated with SendMsg(, SUPER).
Whenever an inherited statement gets redefined in a derived module, this overdefined statement will be valid - in terms of polymorphy - also for the inherited action list (Example).
As soon as inheritance makes a module a base module, its functions are rather limited:
A base module cannot receive a message (see comment); it can only be used to derive further modules.

Windows

Base module windows will also be part of any derived modules. In case the derived module contains a window with the same name, this window will inherit all the base window's child objects - unless it already holds equivalent objects with the same name. The case given, that there are base and derived window child objects with the same name, these equivalent objects have to be positioned at the same level of the Parent-Child-Hierarchy (see Example). The resulting window displays the child object of the derived window (overwrite), which inherits the action list of the base window child object. Here, the same rules apply as for inheriting a module action list (example).

Online Help

If there is no HTML file indicated for the derived module, it inherits the one that has been specified for the base module.

It is not possible to derive a module from a global module or to derive the global one from another module.