Schnittstellen werden heute meist als C-, C++ oder BASIC-Programme codiert. Der Programmieraufwand für die Erstellung einer Schnittstelle ist vor allem im Bereich der GIS-Systeme gross, da neben Sachdaten auch Geometriedaten übertragen werden müssen. Dies führt dazu, dass nur relativ wenige Schnittstellen (hauptsächlich DXF) mit begrenztem Funktionsumfang von den Systemherstellern angeboten werden.

Mit der Entwicklung von ICS wurde ein anderer Weg beschritten. Bei ICS handelt es sich um ein flexibles Schnittstellensystem für die schnelle Entwicklung von Schnittstellenprogammen. Folgende Ideen lagen der Entwicklung von ICS zugrunde:

Nachfolgend ist die Architektur einer ICS-Schnittstelle dargestellt:

Abbildung 1.

	Der Kern und die Input- bzw. Outputmodule werden von der infoGrips GmbH entwickelt. iG/Script-Programme können auch vom Benutzer geschrieben werden.

Der ICS-Kern enthält, neben den allgemeinen Funktionen für die Behandlung von Datenstrukturen (Strings, Geometrie, Maps etc.), einen Interpreter für die iG/Script-Sprache. iG/Script ist eine allgemeine Programmiersprache mit einem vordefinierten Satz von Standardfunktionen. Die Sprache enthält neben arithmetischen-, logischen- und Zuweisungsoperationen, auch Kontrollstrukturen wie IF und WHILE. Daneben bietet sie die Möglichkeit den Sprachumfang durch Prozeduren zu erweitern. Als Basistypen kennt die iG/Script-Sprache die Typen Integer, Real, String, Boolean und Geometrie. Strukturierte Datentypen können über den Datentyp Map erzeugt werden. Input- bzw. Outputmodule können, falls nötig, zusätzliche Datentypen implementieren.

Zu bestehenden Programmiersprachen ist iG/Script am ehesten mit der Programmiersprache FORTH verwandt. Mit FORTH verbindet sie, dass sie ebenfalls alle Operationen über einen Stack abwickelt und eine klammerfreie Darstellung von Ausdrücken verwendet. Der wesentliche Unterschied zwischen FORTH und iG/Script liegt darin, dass FORTH für die hardwarenahe Programmierung entwickelt wurde, iG/Script hingegen ist eine hardwareunabhängige Sprache die sich besonders für die Entwicklung von Schnittstellenapplikationen eignet.

Objekte sind die Basisdatenstruktur von iG/Script. Objekte können mit iG/Script über die Input- bzw. Outputmodule gelesen, geschrieben und über Methoden des Kerns manipuliert werden. Bei den Objekten wird zwischen einfachen und stukturierten bzw. zwischen benannten und unbenannten Objekten unterschieden.

2.2.2. Strukturierte Objekte

Strukturierte Objekte bestehen aus einer oder mehreren Komponenten. Komponenten haben einen Namen und einen Wert. Der Wert einer Komponente kann ein Basystyp oder auch ein Objekt sein, d.h. strukturierte Objekte sind im allgemeinen Fall hierarchisch aufgebaut.

Beispiel 1. IN-Objekt

Ein Objekt, dass vom INTERLIS-Inputmodul ILIN aus der Tabelle LFP gelesen wurde, hat u.a. folgende Komponenten (Entstehung, Nummer, Numpos, etc.):

Komponente	Wert
Entstehung	NULL
Nummer	'1234.223'
Numpos	670530.23/270820.74
...	...

	Strukturierte Objekte werden in iG/Script als sog. Map's implementiert. Mehr dazu in ???.

2.2.5. Benannte Objekte

Die meisten Objekte von iG/Script sind Komponenten des vordefinierten Systemobjekts ROOT. Komponenten von ROOT haben einen Namen über den sie in der Scriptsprache direkt adressiert werden können. z.B. hat das IN-Objekt aus dem ILIN Beispiel im System den Namen ROOT.IN und die Nummer Komponente den Namen ROOT.IN.Nummer.

Abbildung 2.

Der Name des Objekts entspricht also dem Pfad von der Wurzel (ROOT) bis zum Objekt (analog zu Dateinamen in einem Dateibaum). Allgemein kann ein Objekt in iG/Script über folgenden Namen angesprochen werden:

<Objektname> := ROOT.<Komponentename>
<Komponentenname> := <Name> | <Komponentenname> . <Name>
<Name> := <Zeichenkette>

Um die Schreibweise zu vereinfachen, ist es erlaubt ROOT am Anfang des Objektnamens wegzulassen. Die Nummer Komponente des IN-Objekts kann daher in iG/Script auch als IN.Nummer angesprochen werden.

iG/Script arbeitet ähnlich wie ein HP-Taschenrechner, d.h. iG/Script kommt vollständig ohne Klammerung von Ausdrücken aus. Alle Zwischenergebnisse werden auf dem sog. Stack abgelegt. Will man z.B. 1 + 2 berechnen so schreibt man in iG/Script:

1 2 +

weitere Beispiele:

2 1 7 + *

8 5 - 3 /

Konstanten der Basistypen werden sofort auf den Stack geschoben. Sehen wir uns also den Stack während der Berechnung des Ausdrucks 2 * 3 genauer an:

[2]

[2 3]

[6]

In der obigen Darstellung wird der Stack durch [ ... ] repräsentiert (diese Darstellung wurde aus Platzgründen gewählt, normalerweise wird ein Stack oft als senkrechte Kolonne dargestellt). Das am weitesten rechts stehende Objekt wird aktuelles, erstes oder auch oberstes Objekt des Stacks genannt. Alle iG/Script-Methoden nehmen die N obersten Objekte des Stacks als Argumente und liefern M Objekte auf dem Stack als Resultate zurück. Z.B. konsumiert die Multiplikationsmethode 2 Argumente auf dem Stack und liefert nach ihrer Beendigung das Resultat als oberstes Objekt des Stacks zurück.

Neben arithmetischen Methoden kennt iG/Script-Skript weitere Standardmethoden für die Bearbeitung von Strings oder die Ausgabe auf den Bildschirm etc.. Gleichartige Methoden werden zu einer Klasse zusammengefasst (eine Klasse wird durch ein Modul implementiert). Die iG/Script-Standardmethoden gehören z.B. zu der Klasse ICS. Will man eine Methode aus einer bestimmten Klasse aufrufen so schreibt man in iG/Script

also z.B. ILIN.READ_OBJECT (Aufruf der Methode READ_OBJECT aus der Klasse ILIN). Die Standardmethoden sind in der Klasse ICS implementiert. Methoden der Klasse ICS müssen jedoch nicht mit dem Klassennamen qualifiziert werden (ICS.<Methode). Es genügt den Methodennamen anzugeben, die Angabe des Klassennamens ICS ist jedoch erlaubt.

	Man sieht, dass Methoden gleich adressiert werden wie Objekte. Tatsächlich sind Methoden in ICS nichts anderes als Komponenten eines Klassenobjekts.

Damit das nachfolgende Beispiel besser verstanden werden kann, sollen hier kurz einige wichtige Standardmethoden eingeführt werden (eine vollständige Liste der Standardklassen und Standardmethoden ist im Referenzhandbuch enthalten):

Damit sind wir nun in der Lage, ein einfaches iG/Script-Beispiel anzugeben. In dem Beispiel soll die Länge des Strings 'hello, World' berechnet werden und zusammen mit dem String auf den Bildschirm ausgegeben werden. Wir benutzen dazu die Standardmethoden DUP, LEN, APP und DISP.

'hello, World' ! Stack: ['hello, World']
DUP ! Stack: ['hello, World', 'hello, World']
LEN ! Stack: ['hello, World', 12]
APP ! Stack: ['hello, World12']
DISP ! Stack: [] Ausgabe auf Bildschirm: hello, World12

Man sieht an diesem Beispiel wie die Methoden ihre Argumente vom Stack entgegennehmen und ihre Resultate wieder auf dem Stack ablegen. Dieses Verhalten ist für iG/Script typisch.

Oft ist es notwendig, Zwischenresultate einer Berechnung permanent abzulegen. Der Stack ist dazu ungeeignet, da seine Werte durch die Methoden ständig neu überschrieben werden. Für die permanente Speicherung von Objekten verfügt die iG/Script-Sprache deshalb über den Objekttyp Map. Maps müssen durch den Benutzer deklariert werden und zwar vor der ersten ausführbaren Anweisung im Skript. Mapdeklarationen haben folgende Syntax:

MAP TEST
   VAR1 => 'hello, World' 
   VAR2 => 'dies ist ein Test'
END_MAP

In obigem Beispiel enthält das Map-Objekt TEST die Komponenten VAR1 und VAR2. Der Wert von VAR1 ist 'hello, World' und der Wert von VAR2 ist 'dies ist ein Test'. Der Wert einer Komponente kann im Skript mit:

<Mapname>.<Komponentenname>

angesprochen werden (s.a. 2.2). Analog zu den Basistypen wird der Wert einer Komponente sofort nachdem sie im Skript angetroffen wurde auf den Stack geschoben.

TEST.VAR1 ! Stack: ['hello, World']
TEST.VAR2 ! Stack: ['hello, World','dies ist ein Test']
APP ! Stack: ['hello, Worlddies ist ein Test']
DISP ! Stack: [] Bildschirm: hello, Worlddies ist ein Test

Komponenten kann wie folgt ein neuer Wert zugewiesen werden:

oder

Mit => wird jeweils das oberste Objekt des Stacks der Komponente zugewiesen. Mit -> wird nur der Teilstring des obersten Stackelements bis zum ersten Komma zugeordnet (nur bei Stringobjekten möglich). Der Rest des Strings bleibt auf dem Stack erhalten.

'hallo' => TEST.VAR1 ! TEST.VAR1 enthält nun 'hallo' 
                     !Stack: []
'hello, World' -> TEST.VAR1 ! TEST.VAR1 enthält nun 'hello' 
                            ! Stack: [' World']
=> TEST.VAR2 ! TEST.VAR2 enthält nun ' World'
             ! Stack: []

Es ist auch erlaubt nicht existierenden Komponenten einen Wert zu zuweisen (die Map muss allerdings bereits existieren). Will man also z.B. den Wert von TEST.VAR1 und TEST.VAR2 vertauschen so kann man wie folgt vorgehen:

TEST.VAR1 => TEST.TMP ! die Zwischenvariable TEST.TMP wird erzeugt
TEST.VAR2 => TEST.VAR1
TEST.TMP => TEST.VAR2

	Komponenten werden häufig als Variablen in einem iG/Script Programm gebraucht. Für die Speicherung von Variablen stellt ICS daher die vordefinierte Map VAR bereit

Jeglicher Text nach einem ! bis zum Ende der aktuellen Zeile wird in iG/Script als Kommentar aufgefasst.

IN.RADIUS 2.0 * 3.14159 * ! Berechnung des Kreisumfangs

Neben der DISP Methode, gibt es noch eine spezielle eingebaute Methode DISPLAY welche sich besonders für die Ausgabe von Objekten eignet:

Gibt den Wert des Objekts auf den Bildschirm aus

Gibt das oberste Objekt des Stacks aus (analog DISP)

Gibt den Inhalt des Strings und des Objekts aus (z.B. DISPLAY 'TEST.VAR1=',TEST.VAR1). Dabei wird der Wert des Objekts in einen String umgewandelt und am Ende von <String> angehängt. Es dürfen auch mehrere Strings und Objekte in der Liste aufgeführt werden. Die einzelnen Werte müssen jeweils durch ein Komma getrennt werden.

	Neben DISPLAY gibt es die Befehle ERROR und STATUS. Mit ERROR können Fehlermeldungen ausgegeben werden. Der ICS interne Fehlerzähler wird dabei um 1 erhöht. STATUS erlaubt die Ausgabe von Statusmeldungen. Die Syntax von ERROR und STATUS enspricht der Syntax von DISPLAY.

Map-Objekte werden in der iG/Script-Sprache in drei verschiedenen Zusammenhängen gebraucht. Die erste Bedeutung als Variablenspeicher haben wir bereits kennengelernt (s.a. 2.6). Maps können aber auch als Abbildungstabellen oder als Objektspeicher benutzt werden. Betrachten wir z.B. folgende Map:

MAP Jahreszeiten
   Januar => Winter
   Mai => Frühling
   Juni => Sommer
   September => Herbst
END_MAP

Dieses Map-Objekt kann als Abbildungstabelle von Monaten auf Jahreszeiten aufgefasst werden. Schreibt man in iG/Script z.B. 'Januar' Jahreszeiten so wird auf dem Stack 'Winter' abgelegt.

'Januar' Jahreszeiten DISP ! Bildschirm: 'Winter'
'Mai' Jahreszeiten DISP ! Bildschirm: 'Frühling'

Abbildungstabellen können auch kombiniert werden. Es ist z.B. folgende zusätzliche Map definiert

MAP Temperatur
   Winter => kalt
   Sommer => warm
   DEFAULT => mittel
END_MAP

Dann führen die Ausdücke zu folgenden Resultaten:

'Januar' Jahreszeiten Temperatur DISP ! Bildschirm: kalt 
'September' Jahreszeiten Temperatur DISP ! Bildschirm: mittel

Im letzten Beispiel führte die erste Abbildung 'September' Jahreszeiten zu 'Herbst'. 'Herbst' wurde dann durch Temperatur abbgebildet. Da aber keine Komponente Herbst in der Map Temperatur definiert wurde, wurde der Wert der Komponente DEFAULT zurückgeliefert. Falls in einer Map keine DEFAULT-Komponente existiert und auf eine unbekannte Komponente zugegriffen wird, bricht der iG/Script-Interpreter mit einer entsprechenden Fehlermeldung ab.

Die letzte Bedeutung von Maps sind Maps als Objektspeicher. Wie bereits erklärt, liefern die Inputmodule Objekte in einem neutralen Datenformat und geben diese an die Outputmodule weiter. In ICS wurde als Konvention festgelegt, dass Inputmodule ihre Objekte in der Map IN liefern müssen. Ebenfalls als Konvention wurde festgelegt, dass alle Outputmodule ihre Objekte in der Map OUT entgegennehmen müssen.

MAP IN 
   TXT => 'Test' ! Textinhalt 
   GEOM => 740380.150/270810.950 ! Textposition 
   ROT => 270.0 ! Textwinkel 
   FONT => 27 ! Font etc. 
END_MAP

Die IN und die OUT Map können in iG/Script wie jede andere Map bearbeitet werden. Es ist daher möglich die Komponenten als Variablen ('Test2' => IN.TXT), oder die Map als Abbildungstabelle zu interpretieren ('TXT' IN DISP, Bildschirm: Test).

Wie bereits angetönt, kann man mit Listen oder Arrays mehrere Objekte zu einem neuen Objekt zusammenfassen. Für Listen stehen u.A. folgende Methoden zur Verfügung (s.a. Anhang):

CREATE_LIST
'abc' APPEND_TO_LIST
'uvw' APPEND_TO_LIST
=> VAR.L
VAR.L DISP

Obwohl Listen keine Arrays sind, kann man trotzdem auf die einzelnen Elemente einer Liste indiziert zugreifen. Es stehen folgende Indexfunktionen zur Verfügung:

VAR.L.1 ! ['abc']
VAR.L.FIRST ! ['abc']
VAR.L.LAST ! ['uvw']
VAR.L.SIZE ! [2]

Arrays sind spezielle Liste, welche eine fixe, unveränderliche Länge aufweisen. Auf die Elemente eines Arrays kann über einen numerischen Index zugegriffen werden. Der Zugriff auf einzelne Elemente des Arrays ist effizienter möglich als bei Listen. Dafür können Arrays in der Grösse nicht verändert werden.

Für Arrays stehen u.A. folgende Methoden zur Verfügung (s.a. Anhang):

5 CREATE_ARRAY => VAR.A
'abc' => VAR.A.0
'uvw' => VAR.A.1
VAR.A DISP ! ganzen Array anzeigen
VAR.A.0 DISP ! 1. Element des Arrays
VAR.A.1 DISP ! 2. Element des Arrays

Wie die meisten Programmiersprachen verfügt auch iG/Script über Kontrollstrukturen um den Ablauf eines Programms zu steuern. In iG/Script sind die Kontrollstrukturen IF und WHILE enthalten.

Syntax der IF Kontrollstruktur:

Die IF-Kontrollstruktur hat die übliche Bedeutung, d.h. ist die Bedingung1 erfüllt (TRUE) dann wird Ausdruck1 ausgeführt, falls Bedingung2 erfüllt ist dann wird Ausdruck2 ausgeführt etc. Der ELSE und der ELSIF Zweig in einer IF-Kontrollstruktur sind optional. Der ELSIF-Zweig kann beliebig oft wiederholt werden. Eine IF-Kontrollstruktur ist selber wieder ein Ausdruck, d.h. IF-Kontrollstrukturen können geschachtelt werden.

Syntax von Bedingungen:

Bsp: IF TEST.VAR1 = 'hello' THEN 'hello, World' DISP ELSE 'tschüss' DISP END_IF

Syntax der WHILE-Kontrollstruktur

Die WHILE-Kontrollstruktur hat die übliche Bedeutung, d.h. solange die Bedingung erfüllt (TRUE) ist, wird der Ausdruck ausgeführt. Die WHILE-Kontrollstruktur ist selbst wieder ein Ausdruck, d.h. WHILE-Kontrollstrukturen können geschachtelt werden.

! dieses Beispiel zeigt 'hello, World' 10 mal auf
! dem Bildschirm an
0 => VAR.I
WHILE VAR.I < 10 DO 
   'hello, World' DISP 
   VAR.I INC => VAR.I
END_WHILE

Die Ausführung der WHILE-Kontrollstruktur kann an einer beliebigen Stelle mit BREAK oder CONTINUE unterbrochen werden. BREAK verzweigt dabei zur ersten Anweisung nach der WHILE-Kontrollstruktur. CONTINUE verzweigt an den Anfang der WHILE-Kontrollstruktur (d.h. unmittelbar vor die <Bedingung>). Die Anweisungen BREAK und CONTINUE sind nur innerhalb von WHILE-Kontrollstrukturen erlaubt.

! dieses Beispiel zeigt 'hello, World' 10 mal auf
! dem Bildschirm an (Variante mit BREAK)
0 => VAR.I 
WHILE TRUE DO 
   IF VAR.I = 10 THEN
      BREAK 
   END_IF 
   'hello, World' DISP
    VAR.I INC => VAR.I
END_WHILE

	Bei mehrfach geschachtelten WHILE-Kontrollstrukturen, unterbrechen BREAK und CONTINUE jeweils die WHILE-Kontrollstruktur in der sie direkt enthalten sind.

Das letzte Sprachelement von iG/Script, das noch nicht beschrieben wurde, sind die Prozeduren. Mit Prozeduren kann der Benutzer eigene Befehle aus Standardmethoden erzeugen. Prozeduren müssen wie Maps deklariert werden, bevor sie verwendet werden können. Nachfolgend ist die Syntax einer Prozedurdeklaration angegeben:

Wir wollen nun eine neue Prozedur QUADRAT definieren mit der das Quadrat des obersten Elements des Stacks berechnet wird. Das Resultat soll das oberste Element auf dem Stack ersetzen.

PROCEDURE QUADRAT ! [n input][n output]
   DUP *
END_PROCEDURE

	Der Kommentar ! [n input][n output] gibt an welche Argumente die Prozedur auf dem Stack erwartet bzw. welche Resultate die Prozedur auf em Stack zurück liefert. Im Fall der Prozedur QUADRAT wird z.B. ein numerisches Argument (n = Integer oder Real) als Argument erwartet und ein numerisches Resultat auf dem Stack zurück geliefert.

Die neue Prozedur können wir nun wie folgt benutzen:

2 ! Stack: [2]
QUADRAT ! Stack: [4] hier wurde DUP * durchgeführt
DISP ! Stack:[] Bilschirmausgabe: 4

Prozeduren sind also nichts anderes als benannte Teile eines Skripts. Ihre Argumente beziehen Prozeduren meistens über den Stack. Es können allerdings auch Maps für die Parameterübergabe benutzt werden. Folgendes Beispiel benutzt die vordefinierte Map VAR für die Parameterübergabe:

PROCEDURE QUADRAT2
   VAR.VAL 
   DUP * => VAR.VAL
END_PROCEDURE

5 => VAR.VAL
QUADRAT2
VAR.VAL DISP ! liefert als Resultat 25 auf dem Bildschirm

	Prozeduren können an einer beliebigen Stelle mit RETURN verlassen werden

Für die Speicherung von Zwischenresultaten innerhalb der Prozedur steht ausserdem noch die vordefinierte Map LOCAL zur Verfügung. Jede Prozedur hat ihre eigene LOCAL Map welche nicht mit anderen Prozeduren geteilt wird. Der Inhalt der LOCAL Map ist ausserdem nur während der Ausführung der Prozedur definiert. Die LOCAL Map kann also nicht für die Parameterübergabe zwischen Prozeduren benutzt werden (die VAR Map hingegen schon).

PROCEDURE DISPLAY_LIST ! [l list][]
! Diese Prozedur gibt alle Elemente einer Liste aus und
! und benutzt dazu die Map LOCAL als Zwischenspeicher.
   => LOCAL.LIST
   &LOCAL.LIST RESET_READ
   WHILE &LOCAL.LIST READ_NEXT DO
      DISP
   END_WHILE
END_WHILE

Mit iG/Script Direktiven können gewisse Eigenschaften eines iG/Script Programms beinflusst werden. Im Gegensatz zu Methoden oder Prozeduren werden Direktiven nur zu Kompilationszeit durch den iG/Script Compiler ausgeführt.

2.15.1. Die |INCL Direktive

Für die bessere Übersichtlichkeit ist es erlaubt, iG/Script-Programme auf mehrere Textdateien zu verteilen. Mit der |INCL Direktive kann an einer beliebigen Stelle eines Skripts ein weiteres Skriptfile eingebunden werden. Die |INCL Direktive muss am Anfang einer neuen Zeile stehen.

Beispiel 19. Die |INCL Direktive

|INCL ics.lib ! hier wird die Datei ics.lib eingebunden

	In der eingebundenen Datei dürfen ebenfalls |INCL Direktiven stehen.Die einzubindende Datei kann entweder durch einen absoluten Pfad oder relativ zum Installationsverzeichnis von ICS angegeben werden.

Trotz der Unterteilung der Verzeichnisstruktur in ein System- und ein User-Verzeichnis können Dateireferenzen relativ definiert werden.

Die INTERLIS Tools suchen Dateien immer zuerst als absoluter Pfad, dann relativ zum User-Verzeichnis, dann relativ zum System-Verzeichnis, dann relativ zum Verzeichnis ILTOOLS_DIR, dann im gleichen Verzeichnis wie die Konfiguration und zuletzt im gleichen Verzeichnis wie die Konfiguration aber im analogen System-Verzeichnis.

Das nachfolgende Skriptbeispiel einer |INCL Direktive soll dies nochmals verdeutlichen:

! Beispiel ICS Konfiguration: ILTOOLS_DIR\user\script\test\test.cfg
! Diese ICS Konfiguration bindet eine Datei
! relativ zu ILTOOLS_DIR\user und/oder ILTOOLS_DIR\system ein 
|INCL \script\util.lib

1. Zuerst wird die Datei util.lib unter dem absoluten Pfad \script\util.lib gesucht.

   Wird util.lib unter diesem Pfad gefunden so wird sie verarbeitet und nicht weiter gesucht.

   Wird util.lib unter diesem Pfad nicht gefunden, so wird der nächste Schritt durchgeführt.

2. Danach wird die Datei util.lib unter dem Pfad ILTOOLS_DIR\user\script\util.lib gesucht.

   Wird util.lib unter diesem Pfad gefunden so wird diese Version verarbeitet und nicht mehr weiter gesucht.

   Wird util.lib unter diesem Pfad nicht gefunden, so wird der nächste Schritt durchgeführt.

3. Danach wird die Datei util.lib unter dem Pfad ILTOOLS_DIR\system\script\util.lib gesucht.

   Wird util.lib unter diesem Pfad gefunden so wird diese Version verarbeitet und nicht weiter gesucht.

   Wird util.lib unter diesem Pfad nicht gefunden, so wird der nächste Schritt durchgeführt.

4. Danach wird die Datei util.lib unter dem Pfad ILTOOLS_DIR\script\util.lib gesucht.

   Wird util.lib unter diesem Pfad gefunden so wird diese Version verarbeitet und nicht weiter gesucht.

   Wird die util.lib unter diesem Pfad nicht gefunden, so wird der nächste Schritt durchgeführt.

5. Danach wird util.lib unter dem gleichen Pfad wie die ICS Konfiguration unter ILTOOLS_DIR\user\script\test\util.lib gesucht.

   Wird util.lib unter diesem Pfad gefunden so wird sie verarbeitet und nicht weiter gesucht.

   Wird util.lib unter diesem Pfad nicht gefunden, so wird der nächste Schritt durchgeführt.

6. Danach wird util.lib unter dem gleichen Pfad wie die ICS Konfiguration aber unter dem System-Ast ILTOOLS_DIR\system\script\test\util.lib gesucht.

   Wird util.lib unter diesem Pfad gefunden so wird sie verarbeitet und nicht weiter gesucht.

   Wird util.lib unter diesem Pfad nicht gefunden, so wird der nächste Schritt durchgeführt.

7. Es erfolgt eine Fehlermeldung, dass util.lib nicht gefunden werden konnte.

Falls man bewusst eine Datei aus dem System-Verzeichnis verwenden möchte, muss man die Datei relativ zu ILTOOLS_DIR definieren:

! Diese ICS Konfiguration bindet eine Datei
! aus ILTOOLS_DIR\system ein 
|INCL \system\script\util.lib

Falls man eine Datei aus dem gleichen Verzeichnis wie die Hauptkonfiguration verwenden möchte, muss man keinen Pfad definieren.

! Diese ICS Konfiguration bindet eine Datei
! aus dem Verzeichnis der Hauptkonfiguration ein 
|INCL util.lib

Schliesslich kann man eine Datei auch über einen absoluten Pfad ansprechen.

! Diese ICS Konfiguration bindet eine 
! Datei über ihren absoluten Pfad ein
|INCL c:\iltools15\user\script\util.lib

	Es wird jedoch dringend davon abgeraten absolute Pfadnamen in Konfigurationen zu benutzen, weil dadurch die Konfigurationen nicht mehr einfach in andere Verzeichnisse kopierbar sind.

2.15.2. Die |LOAD Direktive

Unter Windows können Input- und Outputmodule als DLL's (Dynamic Link Libraries) implementiert werden. Um die Methoden eines solchen Moduls in der Skriptsprache benutzen zu können, muss der Modul zuerst mit der |LOAD Direktive geladen werden.

Beispiel 20. Die |LOAD Direktive

|LOAD topo ! hier wird das Topologiemodul geladen

	Die |LOAD Direktive muss im Skript vor der ersten ausführbaren Anweisung stehen.Es können mehrere DLL Module pro Skript geladen werden.

2.15.3. Die |LICENSE Direktive

Die meisten iG/Script Programme benötigen für die Ausführung eine gültige Lizenzdatei. Mit der Lizenzdatei wird angegeben, welche Module innerhalb eines Skripts benutzt werden können und ob mit der Lizenz nur versiegelte Scripts ausführbar sind. Die |LICENSE Direktive muss am Anfang einer neuen Zeile stehen.

Beispiel 21. Die |LICENSE Direktive

|LICENSE \license\igimp.lic ! Angabe der Lizenzdatei relativ ! zu IG_IMPORT_DIR

	Die Lizenzdatei kann entweder durch einen absoluten Pfad oder relativ zum Installationsverzeichnis von ICS angegeben werden.

iG/Script-Programme sind für sich allein nicht lauffähig. Sie müssen mit ICS, ICS for Windows, iG/Import oder iG/Export gestartet werden. Lesen Sie dazu das entsprechende Kapitel der Benutzerhandbücher.