5.3 Import mit use

Verfügbarkeit

Ab IDM-Version A.06.02.g

5.3.1 Der alternative Import-Mechanismus

Neben dem Weg, auf ein Modul über ein Import-Objekt zuzugreifen, kann das Schlüsselwort use genutzt werden um den Umgang mit Imports, Modulen, Interface- und Binärdateien zu erleichtern.

Im Gegensatz zum Import erfolgt die Auswahl des Moduls nicht durch einen Dateipfad auf die Interface-Datei, sondern über einen Bezeichner-Pfad – genauer gesagt dem Use-Pfad.

Der letzte Bezeichner im Use-Pfad ist, analog zum Bezeichner eines Imports, der Vater-Bezeichner mit dem die exportierten Objekte im importierenden Modul bekannt gemacht werden. Die vorderen Bezeichner im Use-Pfad definieren eine Paket-Hierarchie und können somit zur Untergliederung der Module genutzt werden. Bei der Evaluation von Objekt-Pfaden bleiben diese Teile unberücksichtigt.

Beispiel

!! file: Main.dlg

dialog MainDlg

use Models;
use Base.Fonts;

MWiMain WiMain {
  .font Fonts.FnBig;
}

!! file: Models.mod

module ModModels

export window MWiMain {
  on close {
    exit();
  }
}

!! file: Base/Fonts.mod

module ModFonts

export font FnBig "24.Arial";

Die Verzeichnisse, in denen die eigentliche Modul- und Interface-Datei gesucht werden, können als Startoption oder eine spezielle Umgebungsvariable, über einen Auf ruf von DM_ControlEx() oder in der Regelsprache gesetzt werden.

Das Vorhandensein einer Interface-Datei ist dabei nicht zwingend notwendig, aber sinnvoll um das Laden von Modulen ohne direkte Nutzung zu erleichtern und das Nachladen der Implementierung bei Bedarf zu unterstützen.

5.3.1.1 Besonderheiten

Module die über use angezogen werden, sind im Dialog immer nur einmal geladen. Dieser Umstand erleichtert die Verwendung von Basismodulen, da nicht versehentlich durch eine fehlerhafte Import-Kette ein Modul mehrfach geladen wird.

Die Entkopplung von einem Interface- oder Modul-Dateinamen hat mehrere Vorteile:

1. Die Verwendung von eigenen Umgebungsvariablen für den Ort der Interface- und Binärmodule entfällt.
2. Die Erzeugung der Interface- und Binärdateien wird vereinfacht.
3. Das Laden von Modulen ohne Interface-Datei ist nun möglich, da ein zentraler Suchpfad für Interfaces, Module und Binärmodule vorhanden ist.

Eine weitere Besonderheit ist die Vorgabe von Dateiendungen (Datei-Suffixe) für Quelltext-Dateien (.dlg und .mod), Interface-Dateien (.if) und Binärdateien (.bin).

Die Umsetzung von einem Use-Pfad zu einem Dateipfad geschieht dabei wie folgt: Die vorangestellten Paketbezeichner entsprechen einem Verzeichnispfad, der letzte Bezeichner dem Basisnamen des Moduls.

Das heißt im Beispiel oben ergibt sich für den Use-Pfad Base.Fonts der Basis-Dateiname Base\Fonts. Das Quelltext-Modul heißt Base\Fonts.mod, die dazugehörige Interface-Datei Base\Fonts.if und das Binärmodul Base\Fonts.bin.

Wird nun über use Base.Fonts ein Modul angezogen, dann wird im Suchpfad nach diesen drei Dateinamen gesucht um das Interface bzw. die Implementierung zu laden. In der Entwicklungsversion des IDM wird dabei in der Reihenfolge Interface-Datei → Quelltextdatei → Binärmodul vorgegangen. Die Laufzeitversion des IDM kann nur Binärdateien laden.

Einige weitere Unterschiede zum Import-Objekt sind noch vorhanden: Es gibt keine Steuermöglichkeiten über die Attribute .application, .static und .load. Es wird immer versucht, erst das Interface heranzuziehen und dann die Implementierung (Quelltext, Binär). Die Implementierung wird nur wenn benötigt nachgeladen. Ein direkte Steuerung des Ladens entfällt somit.

Für ein dynamisches Laden und Entladen gibt es die neuen Methoden :use() und :unuse().

Grundsätzlich können Binärmodule und Interface-Dateien, die für die Nutzung durch ein Import-Objekt erzeugt wurden, unverändert auch mit use genutzt werden. Umgekehrt gilt dies nicht zwangsläufig da hier meist der Hinweis auf den Modulpfad im Interface fehlt.

5.3.1.2 Groß- und Kleinschreibung in Dateinamen

Sie ist im IDM bei Bezeichnern und somit auch beim Use-Pfad sowie für die Dateinamen von Bedeutung!

5.3.1.3 Empfehlungen

Zwar ist eine gemischte Nutzung von import und use möglich, aber nicht empfehlenswert, da das Import-Objekt ein mehrfaches Laden von Modulen provoziert. Deshalb wird empfohlen, komplett von import auf use umzustellen.

Außerdem wird empfohlen , für Datei- und Verzeichnisnamen grundsätzlich die gleiche Schreibweise wie im Use-Pfad zu wählen. Am besten sollten Module einen eindeutigen Namen besitzen, der auch nicht in einer abgewandelten Form mit anderer Groß- und Kleinschreibung auftaucht.

Statt ein Modul über import zu laden, sollte man Modelle verwenden, die problemlos mehrfach instanziiert werden können.

5.3.2 Sprachbeschreibung und Use-Pfad

Folgende Sprachbeschreibung gilt für das Schlüsselwort use:

{ export | reexport } use { <Use-Pfad> }

<Use-Pfad>   ::= [ <Paket-Pfad> ] <Bezeichner>
<Paket-Pfad> ::= [ <Paket-Pfad> ] <Bezeichner> .

Die Bezeichner sollten mit einem Großbuchstaben anfangen ('A' – 'Z') und kann danach auch Kleinbuchstaben, Ziffern und Unterstriche ('_') enthalten. Ein Bezeichner darf maximal 31 Zeichen haben.

Beispiele für gültige use-Verwendungen

use Defaults;
use DEFAULTS;
use Max_Wi09_;
use Modul78.Aa.MasterA__1z;
use BaseMod.M_ods.Wins.MWiEnter1_9;

Der Use-Pfad besteht dabei aus einem Bezeichner (Identifikator) am Ende und repräsentiert den Basisnamen des Moduls, sowie den Vater-Bezeichner für den weiteren Zugriff auf die exportierten Objekte (falls diese nicht eindeutig aufzulösen sind). Dieser Bezeichner muss nicht dem Modulbezeichner entsprechen.

Der Paket-Pfad wiederum dient zur logischen Untergliederung von mehreren Modulen und wird bei der Suche nach dem Modul als Verzeichniskette vorangestellt.

5.3.3 Use-Pfad, Dateinamen und Namensrestriktionen

Der IDM konvertiert intern einen Use-Pfad in einen Dateipfad, um diesen bei der Suche von Interface-Datei, Quelltextdatei oder Binärmodul zu verwenden.

So wird der Use-Pfad Modul78.Aa.MasterA__1z zum Dateipfad Modul78\Aa\MasterA__1z.

Außerdem gibt es einen vorgegebenen Satz von Dateiendungen, die bei Suche und Zugriff relevant sind und intern an den Basis-Dateipfad angehängt werden:

Da der Use-Pfad über IDM-Bezeichner aufgebaut ist, bedeutet dies natürlich, dass Datei- und Verzeichnisnamen mit einem Großbuchstaben beginnen können sowie die Groß- und Kleinschreibung eine Bedeutung hat und wichtig ist! Dies ist bei der Nutzung auf Dateisystemen, die dies nicht unterscheiden, zu beachten.

Das heißt im IDM gilt: use Default; ist etwas anderes als use DEFAULT;. Unter Windows kann das Modul aber durchaus bei Vorhandensein der Modul-Datei DEFault.Mod gefunden werden.

Grundsätzlich kann auch der Dialog über einen Use-Pfad angesprochen (geladen) werden.

Falls unüberbrückbare Probleme bei der Umwandlung zwischen Use-Pfad und Dateipfad bestehen, kann das interne Konvertierungsverhalten über die Option ‑IDMusepathmodifier gesteuert werden.

5.3.4 Suchpfad für Interface-, Modul-, Dialog- und Binärdateien

Der IDM besitzt einen zentralen Suchpfad für das Auffinden von IDM-Dateien. Dieser Suchpfad kann eine oder mehrere absolute oder relative Verzeichnisangaben mit Semikolon (;) getrennt beinhalten.

Standardmäßig ist der Suchpfad auf ~; gesetzt, also auf den Sonderpfad ~ und den Leerpfad "". Diese haben folgende Bedeutung:

Bei der Suche nach einer IDM-Datei, z.B. über DM_LoadDialog() oder die eingebaute Funktion load(), wird wie folgt vorgegangen:

1. Wenn der angegebene Pfad absolut ist, wird die Datei an dem exakt angegebenen Pfad gesucht ohne das Anhängen einer Erweiterung (kompatibles Verhalten wie bisher).
2. Handelt es sich um einen relativen Pfad mit Dateierweiterung, wird dieser im Suchpfad mit exakt dieser Erweiterung gesucht. Dabei stellt der Standard-Eintrag "" (Leerpfad) das kompatible Verhalten wie bisher dar.
3. Ist am Dateinamen keine Erweiterung vorhanden, werden je nach Aktion die möglichen Erweiterungen bei allen Suchpfaden durchprobiert. Zum Beispiel werden bei DM_LoadDialog() die Erweiterungen .dlg, .mod, .bin durchprobiert. Bei einem use wird versucht, mit Vorrang das Interface zu bekommen, also wird die Reihenfolge .if, .bin, .mod durchprobiert.

Folgende Einstellmöglichkeiten für den Suchpfad sind vorhanden:

• Beim Start einer IDM-Anwendung über die Option -IDMsearchpath <Suchpfad>.
• Über die Umgebungsvariable IDM_SEARCHPATH.
• Durch den Aufruf von DM_ControlEx() mit DMF_SetSearchPath und dem Suchpfad als data-Argument.
• Über das Attribut .searchpath am Setup-Objekt.

Für eine selbst kompilierte IDM-Anwendung empfehlen wir die Nutzung von DM_ControlEx() in der AppMain()-Routine mit Angabe eines Applikations-relativen Pfades über ~ und ohne andere relative Angaben wie den Leerpfad oder ".". So würde die Ausführung von DM_ControlEx((DM_ID)0, DMF_SetSearchPath, "~:dlg") sicherstellen, dass die Dialogdateien nur im Unterverzeichnis dlg parallel zur Anwendung gesucht werden. Ist der Suchpfad erst einmal gesetzt, kann dann auch über DM_LoadDialog() das initiale Laden des Hauptdialogs über einen relativen Dateipfad ohne Dateiendung erfolgen.

Beispiele für korrekte und erlaubte Suchpfade

Beim Öffnen und Laden von IDM-Dateien versucht der IDM den Dateityp festzustellen, um zu erkennen, ob die Datei eine Interface-Datei, ein Dialog, Modul oder eine Binärdatei ist. Zu diesem Zweck untersucht er die ersten 1.024 Bytes der Datei, ob sie die Signatur für eine IDM-Binärdatei hat, oder entsprechende Schlüsselwörter die ein Interface, Dialog oder Modul kennzeichnen. Andernfalls wird die Dateiendung zur Bestimmung herangezogen.