Modules (definition)

Modules

Module(name [, HELP(fileName)])

[[,] Synopsis(text1, text2, ..., textm)]
[[,] Dictionary(T(keyWord11, keyWord12, ..., keyWord1m), ..., T(keyWordn1, ..., keyWordnm))]

The InstantView® interpreter reads over the descriptive information for synopsis and dictionary.
If InstantView® code is read with the function ParseLib() of the SystemObject - for the InstantView® browser - this information is also evaluated.

The window objects defined with InstantView®, their action lists, the variables and statements defined therein are always assigned to a module. The statement 'Module' determines that all following definitions belong to this module.
Each module creates its own namespace for variables, user-defined statements and window objects. There is a predefined module named 'GLOBAL' with the special property that variables, statements and window objects introduced there are globally visible.

The same applies to module 'SYSTEM', which was used by the ClassiX® Workbench. The purpose of this module was to separate variables and instructions of the workbench from those of the project processed with the workbench. Module 'SYSTEM' is helpful when InstantView® is applied to itself.
Module 'SYSTEM' should not be used, because this feature will not be developed further!

Modules determine the scope of local InstantView® variables, statements and window objects. An overview of the visibility of InstantView® elements can be found here.

Inheritance

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

[[,] Synopsis(text1, text2, ..., textm)]
[[,] Dictionary(T(keyWord11, keyWord12, ..., keyWord1m), ..., T(keyWordn1, ..., keyWordnm))]

The newly introduced module is derived from an already defined module. The inheritance concept realised here follows the principles of object orientation: elements of the basic module are adopted, unless they are overdefined by an element with the same name in the derived module. In detail this means:

Variable

If the variable x exists in the base module, the derived module also has a variable with this name. The variable acquired by inheritance is local like an explicitly agreed variable, i.e. a change in value of variable x of another derived module has no effect on x (see example).
Since variables do not have any special characteristics, the overdefinition of a variable is rather pointless - the result would again be just a variable x, which the module already has anyway.

Statement

If a statement s was agreed in the basic module, this statement is also known in the derived module, unless a new variant of s is defined there. Within the new definition, which is often an extension of the old statement, one can refer to the statement of the base module with the notation

super::s

or with

moduleName::s

call the statement definition in a specific base module located on the inheritance path. 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 there!) (example).

174605 the call with module name is no longer supported(name::s is reserved for import via provider )

Action list

The action list of a basic module is also transferred. In the derived module the reaction to a certain event can be overwritten by simply redefining it there. Instead of the action defined in the base module, the action overwritten in the derived module is now triggered. The overwritten instructions can only be activated with SendMsg(, SUPER).
If an inherited instruction is redefined in the derived module, this redefined instruction - in the sense of polymorphism - also becomes effective for the inherited action list(example).
As soon as another module is derived from a module, i.e. it becomes the basic module - its function is limited:
A base module itself cannot receive messages (see remark); it can only be used to derive further modules.

Windows

Windows belonging to the base module also become part of derived modules. If the derived module contains a window with the same name, this window inherits all child objects of the base window for which no counterpart with the same name exists in the derived window. If the base and derived windows have child objects with the same name, they must be on the same level in the parent-child hierarchy (compare example). The child object of the derived window appears in the resulting window (overwrite), but it inherits the action list of the child object from the base window. The same rules apply as for the inheritance of the action list of a module(example).

Here is an explanation of the exact process of widget inheritance and the concrete rules can be found here.

Online help

If no separate HTML file is specified for the derived module, it will inherit the file specified for the base module.

No modules can be derived from the global module. It is also not allowed to derive the global module from another module.