Lade...
 

Module (Definition)

Module

Syntax
Module(name [, HELP(fileName)]) [[,] Synopsis(text1, text2, ..., textm)] [[,] Dictionary(T(keyWord11, keyWord12, ..., keyWord1m), ..., T(keyWordn1, ..., keyWordnm))]
Parameter
Parameter   Beschreibung
name   ein eindeutiger Name
fileName   Dokumentation und Online-Hilfe als HTML-File
Synopsis   kurze Inhaltsangabe
Dictionary   beschreibende Stichworte 

Die beschreibenden Angaben zu Synopsis und Dictionary werden vom InstantView®-Interpreter überlesen.
Wenn InstantView®-Code mit Funktion ParseLib() des SystemObjects gelesen wird - für den InstantView®-Browser - wird diese Information mit ausgewertet.

Die mit InstantView® definierten Windowobjekte, ihre Aktionslisten, die darin definierten Variablen und Statements sind immer einem Modul zugeordnet. Die Anweisung 'Module' bestimmt, dass alle folgenden Definitionen zu diesem Modul gehören.
Jeder Modul erzeugt einen eigenen Namensraum für Variable, anwenderdefinierte Statements und Windowobjekte. Es existiert ein prädefinierter Modul mit dem Namen 'GLOBAL' und der besonderen Eigenschaft, dass dort eingeführte Variable, Statements und Windowobjekte global sichtbar sind.

Das gleiche gilt für Modul 'SYSTEM', das von der ClassiX®-Workbench benutzt wurde. Der Sinn dieses Moduls war, Variable und Anweisungen der Workbench von denen des mit der Workbench bearbeiteten Projekts zu trennen. Modul 'SYSTEM' ist hilfreich, wenn InstantView® auf sich selbst angewendet wird. 
Modul 'SYSTEM' soll nicht verwendet werden, da dieses Feature nicht weiterentwickelt wird!

Module bestimmen den Gültigkeitsbereich (Scope) der lokalen InstantView®-Variablen, Anweisungen und Windowobjekte. Eine Übersicht zur Sichtbarkeit der Elemente von InstantView® finden sie hier.  

Vererbung

Syntax
Module(name[, HELP(fileName)]) : baseModName [[,] Synopsis(text1, text2, ..., textm)] [[,] Dictionary(T(keyWord11, keyWord12, ..., keyWord1m), ..., T(keyWordn1, ..., keyWordnm))]
Parameter
Parameter Beschreibung
name ein eindeutiger Name
fileName Dokumentation und Online-Hilfe als HTML-File
baseModName Name eines bereits definierten Moduls
Synopsis kurze Inhaltsangabe 
Dictionary beschreibende Stichworte  

 

Der neu eingeführte Modul ist von einem bereits definierten Modul abgeleitet. Das hier realisierte Vererbungskonzept folgt den Prinzipien der Objektorientierung: Elemente des Basismoduls werden übernommen, sofern sie nicht durch ein namensgleiches Element im abgeleiteten Modul überdefiniert sind. Im Einzelnen bedeutet dies:

Variable

Existiert im Basismodul die Variable x, so besitzt der abgeleitete Modul ebenfalls eine Variable mit diesem Namen. Die durch Vererbung erworbene Variable ist wie eine explizit vereinbarte Variable lokal, d.h. eine Wertänderung der Variablen x eines weiteren abgeleiteten Moduls hat keine Auswirkung auf x (siehe Beispiel).
Da Variable keine besonderen Merkmale besitzen, ist die Überdefinition einer Variablen ziemlich sinnlos - das Ergebnis wäre ja wieder nur eine Variable x, die der Modul ohnehin schon besitzt.

Statement

Wurde im Basismodul ein Statement s vereinbart, so ist dieses Statement auch im abgeleiteten Modul bekannt, es sei denn, dort wird eine neue Variante von s definiert. Innerhalb der Neudefinition, die oft eine Erweiterung der alten Anweisung ist, kann man sich auf das Statement des Basismoduls mit der Schreibweise

super::s

beziehen, oder mit

moduleName::s

die Statement-Definition in einem bestimmten, auf dem Inheritance-Pfad liegenden Basismodul aufrufen. Mit dieser Konstruktion - Modulname und Scope-Operator :: - sind innerhalb einer Anweisungsdefinition (und nur dort!) die Originalversionen aller direkt oder indirekt geerbten Anweisungen erreichbar (Beispiel).
 

174605 ist der Aufruf mit Modulname nicht mehr unterstützt (name::s ist für Import über Provider reserviert)

Aktionsliste

Auch die Aktionsliste eines Basismoduls wird übernommen. Im abgeleiteten Modul kann die Reaktion auf ein bestimmtes Ereignis überschrieben werden, indem man sie dort einfach neu definiert. Statt der im Basismodul definierten wird jetzt die im abgeleiteten Modul überschriebene Aktion getriggert. Die überschriebenen Anweisungen können nur noch mit SendMsg(, SUPER) aktiviert werden.
Wird im abgeleiteten Modul eine vererbte Anweisung neu definiert, so wird - im Sinne der Polymorphie - diese überdefinierte Anweisung auch für die geerbte Aktionsliste wirksam (Beispiel).
Sobald von einem Modul eine anderer abgeleitet wird, d.h. er wird zum Basismodul - ist seine Funktion eingeschränkt:
Ein Basismodul selbst kann keine Messages empfangen (siehe Bemerkung); er kann nur noch zur Ableitung weitere Module verwendet werden.         

Windows

Zum Basismodul gehörende Windows werden auch Bestandteil abgeleiteter Module. Enthält das abgeleitete Modul ein Window mit gleichem Namen, so erbt dieses Window alle Childobjekte des Basis-Windows für die im abgeleiteten Window kein gleichnamiges Gegenstück existiert. Wenn Basis- und abgeleitetes Window Childobjekte gleichen Namens besitzen, müssen diese auf gleicher Stufe in der Parent-Child-Hierarchie stehen (vergleiche Beispiel). Im resultierendem Window erscheint das Childobjekt des abgeleiteten Windows (overwrite), das aber die Aktionsliste des Childobjektes aus dem Basiswindow erbt. Dabei gelten die gleichen Regeln wie bei der Vererbung der Aktionsliste eines Moduls (Beispiel).

Hier ist eine Erläuterung des genauen Ablaufs der Widgetvererbung und der konkreten Regeln findet sich hier.

Online-Hilfe

Wird für den abgeleiteten Modul keine eigene HTML-Datei angegeben, erbt er das beim Basismodul festgelegte File.

Vom globalen Modul können keine Module abgeleitet werden. Auch die Ableitung des globalen Moduls von einem anderen Modul ist nicht erlaubt.