Richtlinien zur Typisierung

Version 2004 (Geändert)

Dieser Abschnitt beschreibt die wichtigsten Gründe für Konflikte bei typisierten Variablen und zeigt Wege, sie zu vermeiden.

Konflikte bei einfachen Variablen

Es gibt folgende Varianten:

• Konflikt zwischen zwei Verwendungen,

• Konflikt zwischen Verwendung und Compiler Direktive,

• Konflikt durch implizierte Retypisierung,

• Konflikt zwischen zwei Compiler Direktiven.

Der einfachste Konflikt bei Datentypen ist ein Variablenname, der zwei unterschiedliche Objekte angibt. Sie schreiben zum Beispiel:

   Variable:=5

und in derselben Anwendung an anderer Stelle:

   Variable:=Wahr

Das ergibt einen Datentypkonflikt. Sie beheben das Problem, wenn Sie eine der Variablen umbenennen.

Nehmen wir an, Sie schreiben:

   Variable:=5

und in derselben Anwendung an anderer Stelle:

   C_BOOLEAN(Variable)

Da der Compiler zuerst die Direktiven durchläuft, typisiert er Variable als Boolean, stößt er dann auf die Anweisung:

   Variable:=5

ergibt das einen Datentypkonflikt. Sie beheben das Problem, wenn Sie eine der Variablen umbenennen oder die Compiler Direktive ändern.

Verwenden Sie in derselben Anweisung Variablen mit unterschiedlichen Datentypen, führt das zu Inkonsistenz. Der Compiler meldet Unstimmigkeiten. Hierzu ein Beispiel:

   vBool:=True    `Der Compiler folgert, dass vBoolean vom Typ Boolean ist
   C_INTEGER(<>vInteger)   `Deklaration einer Ganzzahl durch Compiler Direktive
   <>vInteger:=3   `Befehl stimmt mit der Compiler Direktive überein
   Var:= <>vInteger+vBool   `Operation enthält Variablen mit inkompatiblen Datentypen

Einige Funktionen geben Variablen mit einem ganz bestimmten Datentyp zurück. Weisen Sie das Ergebnis einer solchen Variablen einer Variablen zu, die bereits anders typisiert wurde, ergibt sich u.U. ein Datentypkonflikt.

Sie schreiben zum Beispiel in einer interpretierten Anwendung:

   IdentNo:=Request("KennNummer")   IdentNo ist vom Typ Text
   If(Ok=1)
      IdentNo:=Num(IdentNo)   `IdentNo ist vom Typ Zahl
      QUERY([Kunden]No=IdentNo)
   End if

In diesem Beispiel erzeugen Sie in der dritten Zeile einen Datentypkonflikt. Hier müssen Sie das Verhalten der Variablen steuern. In einigen Fällen müssen Sie eine Variable mit einem anderen Namen dazwischenlegen. In anderen Fällen müssen Sie Ihre Methode anders strukturieren:

   IdentNo:=Num(Request("KennNummer"))  `IdentNo ist vom Typ Zahl
   If(Ok=1)
      QUERY([Kunden]No=IdentNo)
   End if

Deklarieren Sie dieselbe Variable über zwei unterschiedliche Compiler Direktiven, bedeutet das eine Retypisierung. Schreiben Sie in der gleichen Datenbank:

   C_BOOLEAN(Variable)
   C_TEXT(Variable)

entdeckt der Compiler den Konflikt und meldet einen Fehler. Sie beheben das Problem, wenn Sie eine der Variablen umbenennen.

Beim Einsatz von C_STRING kann ein Datentypkonflikt auftreten, wenn Sie die maximale Stringlänge verändern. Schreiben Sie zum Beispiel:

   C_STRING(5;MyString)
   MyString:="Hallo"
   C_STRING(9;MyString)
   MyString:="Guten Tag"

sieht der Compiler einen Konflikt, da er beim Deklarieren von String Variablen einen Platz in der passenden Größe liefern muss.

Sie lösen das Problem durch eine Compiler Direktive mit der maximalen Länge, da der Compiler standardmäßig eine kürzere Zeichenkette akzeptiert. Sie können schreiben:

   C_STRING(9;String)
   String:="Guten Tag"
   String:="Hallo"

Hinweis: Haben Sie C_STRING(9;String) zweimal geschrieben, z.B.:

   C_STRING(9;String)
   String:="Guten Tag"
   C_STRING(9;String)
   String:="Hallo"

akzeptiert der Compiler die Direktiven; die zweite Direktive ist dann lediglich redundant.

Lokale Variablen haben dieselben Datentypkonflikte wie Prozess- oder Interprozessvariablen. Der einzige Unterschied ist, dass die Konsistenz nur innerhalb der angegebenen Methode vorhanden sein muss.

Bei Prozess- oder Interprozessvariablen treten Konflikte auf der allgemeinen Ebene der Datenbank auf, bei lokalen Variablen auf Methodenebene. Sie können also in derselben Methode nicht schreiben:

   $Temp:="Guten Tag" 

und dann

   $Temp:=5

Sie können jedoch in Methode M1 schreiben:

   $Temp:="Guten Tag"

und in Methode M2:

   $Temp:=5

da sich die Reichweite von lokalen Variablen nur auf die Methode selbst erstreckt und nicht auf die gesamte Datenbank.

Konflikte in einem Array betreffen nie die Größe, da Arrays, wie in unkompilierten Datenbanken, dynamisch verwaltet werden. Die Größe eines Arrays kann je nach Methode unterschiedlich sein. Sie müssen für ein Array auch keine max. Größe deklarieren.

Sie können also ein Array auf Null setzen, Elemente hinzufügen bzw. entfernen oder den Inhalt löschen.

Beachten Sie beim Erstellen einer Datenbank, die kompiliert werden soll, folgende Regeln:

• Verändern Sie nicht die Datentypen von Elementen des Array,

• Verändern Sie nicht die Anzahl der Dimensionen in einem Array,

• Verändern Sie bei einem Array vom Typ String nicht die definierte Länge der Zeichenkette.

Deklarieren Sie ein Array als Ganzzahl, muss dieses Array vom Typ Ganzzahl für die ganze Datenbank erhalten bleiben. Es kann also nicht Elemente vom Typ Boolean enthalten.

Schreiben Sie:

   ARRAY INTEGER(MyArray;5)
   ARRAY BOOLEAN(MyArray;5)

kann der Compiler MyArray nicht typisieren.

In diesem Fall müssen Sie ein Array umbenennen.

In einer unkompilierten Datenbank können Sie die Anzahl der Dimensionen in einem Array verändern. Der Compiler verwaltet jedoch beim Erstellen der Symboldatei eindimensionale Arrays anders als zweidimensionale Arrays.

Folglich können Sie ein eindimensionales Array nicht umändern in ein zweidimensionales, oder umgekehrt.

Die gleiche Datenbank kann als nicht enthalten:

   ARRAY INTEGER(MyArray1;10)
   ARRAY INTEGER(MyArray1;10;10)

Sie können jedoch in derselben Anwendung schreiben:

   ARRAY INTEGER(MyArray1;10)
   ARRAY INTEGER(MyArray2;10;10)

Sie können in einer Datenbank nicht die Anzahl der Dimensionen, jedoch die Größe eines Array ändern, also z.B. ein Array in einem zweidimensionalen Array verändern:

   ARRAY BOOLEAN(MyArray;5)
   ARRAY BOOLEAN(MyArray;10)

Hinweis: Ein zweidimensionales Array setzt sich aus mehreren eindimensionalen Arrays zusammen. Weitere Informationen dazu finden Sie im Abschnitt Zweidimensionale Arrays.

Für String Arrays gelten dieselben Regeln wie für feste Strings.

Schreiben Sie:

   ARRAY STRING(5;MyArray;10)
   ARRAY STRING(10;MyArray;10)

entdeckt der Compiler einen Längenkonflikt. Sie beheben das Problem, wenn Sie die maximale Stringlänge deklarieren. Der Compiler verwaltet automatisch kürzere Stringlängen.

Bei Befehlen wie COPY ARRAY, LIST TO ARRAY, ARRAY TO LIST, SELECTION TO ARRAY, SELECTION RANGE TO ARRAY, ARRAY TO SELECTION oder DISTINCT VALUES können Sie wissentlich oder unwissentlich die Datentypen von Elementen, die Anzahl der Dimensionen oder in einem String Array die Stringlänge verändern. Sie befinden sich also in einer dieser drei Situationen.

Der Compiler generiert eine Fehlermeldung; die erforderliche Korrektur ist meist ganz offensichtlich. Beispiel für implizierte Retypisierung finden Sie im Abschnitt Syntax Details.

Wollen Sie eine Datenbank mit lokalen Arrays kompilieren, d.h. sie sind nur in den Methoden sichtbar, die sie erstellt haben, müssen Sie diese vor der Verwendung explizit in 4th Dimension deklarieren.

Ein Array explizit deklarieren heisst, einen Befehl vom Typ ARRAY REAL, ARRAY INTEGER, etc. verwenden. Erstellt eine Methode zum Beispiel ein lokales Array vom Typ Ganzzahl mit 10 Elementen, sollte Ihre Methode folgende Zeile enthalten:

   ARRAY INTEGER($MyArray;10)

In Formularen erstellte Variablen sind immer Prozess- oder Interprozessvariablen. Das können Schaltflächen, DropDown-Listen, etc. sein.

In einer interpretierten Datenbank ist der Datentyp solcher Variablen unwichtig. In kompilierten Anwendungen müssen Sie dagegen darauf achten. Die Regeln dafür sind denkbar einfach:

• Sie können diese Variablen mit Compiler Direktiven typisieren, oder

• Der Compiler weist ihr einen Standardtyp zu, den Sie in den Kompilierungseinstellungen definieren können. Weitere Informationen dazu finden Sie im Handbuch 4th Dimension Designmodus.

Kontrollkästchen

3D Kontrollkästchen

Schaltfläche

Invertierte Schaltfläche

Unsichtbare Schaltfläche

3D Schaltfläche

Bildschaltfläche

Schaltflächengitter

Optionsfeld

3D Optionsfeld

Bildoptionsfeld

Bildmenü

Hierarchisches PopUp-Menü

Hierarchische Liste

Lineal

Halbkreisskala

Thermometer.

Hinweis: Die Formularvariablen Lineal, Halbkreisskala und Thermometer werden immer als Zahl typisiert, selbst wenn Sie in den Einstellungen zur Kompilierung als Schaltflächentyp Lange Ganzzahl definieren.

Für diese Variablen kann ein Datentypkonflikt nur auftreten, wenn der Name einer Variablen mit einer an anderer Stelle gesetzten Variablen identisch ist. Geben Sie in diesem Fall der zweiten Variablen einen anderen Namen.

Ein Diagrammbereich ist automatisch vom Datentyp Diagramm (Lange Ganzzahl). Diese Variable verursucht keinen Datentypkonflikt, außer der Name einer Variablen dieses Typs ist mit einer an anderer Stelle gesetzten Variablen identisch. Geben Sie in diesem Fall der zweiten Variablen einen anderen Namen.

Ein Plug-In Bereich ist immer vom Typ Lange Ganzzahl. Diese Variable verursucht keinen Datentypkonflikt, außer der Name einer Variablen dieses Typs ist mit einer an anderer Stelle gesetzten Variablen identisch. Geben Sie in diesem Fall der zweiten Variablen einen anderen Namen.

Nicht eingebbare Variable,

Eingebbare Variable,

DropDown Liste,

Menü/DropDown Liste,

Rollbarer Bereich,

Combo Boxen,

PopUp Menü,

Registerkarte.

Diese Variablen sind in zwei Kategorien unterteilt:

• Einfache Variablen (eingebbare und nicht eingebbare Variablen),

• Anzeigevariablen (DropDown Listen, Menüs/Dropdown Listen, rollbare Bereiche, PopUp-Menüs, Combo Boxen und Registerkarten).

• Einfache Variablen

Sie sind standardmäßig vom Typ Text. Bei Verwendung in Methoden oder Objektmethoden haben sie den von Ihnen zugewiesenen Typ. Ein Datentypkonflikt ergibt sich nur, wenn der Name einer Variablen dieses Typs mit einer an anderer Stelle gesetzten Variablen identisch ist.

• Anzeigevariablen

Einige Variablen dienen zur Anzeige von Arrays in Formularen. Wurden im Formulareditor Standardwerte eingetragen, müssen Sie die dazugehörigen Variablen mit den Befehlen zum Deklarieren der Arrays explizit deklarieren, also z.B. ARRAY STRING, ARRAY TEXT....

Enthält Ihre Datenbank Zeiger, nutzen Sie die Vorteile eines leistungsstarken und ausgeklügelten Werkzeugs von 4th Dimension. Der Compiler bewahrt alle Vorzüge von Zeigern.

Ein Zeiger kann auf Variablen mit verschiedenen Datentypen verweisen. Sie vermeiden Konflikte, wenn Sie einer Variablen nicht verschiedene Datentypen zuweisen. Achten Sie darauf, dass der Datentyp einer Variablen, auf die sich ein Zeiger bezieht, nicht verändert wird.

Hierzu ein Beispiel:

   Variable:=5.3
   Zeiger:=-> Variable 
   Zeiger->:=6.4
   Zeiger->:=Falsch

In diesem Fall ist der dereferenzierte Zeiger eine Variable vom Typ Zahl. Weisen Sie diesem einen Wert vom Typ Boolean zu, erzeugen Sie einen Datentypkonflikt.

Benötigen Sie Zeiger in derselben Methode für verschiedene Zwecke, achten Sie auf die korrekte Definition:

   Variable:=5.3
   Zeiger:=-> Variable 
   Zeiger->:=6.4
   Bool:=Wahr
   Zeiger:=->Bool
   Zeiger->:=Falsch

Ein Zeiger wird immer in Bezug auf das Objekt definiert, auf welches er zeigt. Deshalb kann der Compiler vom Zeiger verursachte Datenkonflikte nicht finden. Bei einem Konflikt erhalten Sie keine Fehlermeldung während der Typisierungs- oder Kompilierungsphase.

Das bedeutet jedoch nicht, dass der Compiler Konflikte im Zusammenhang mit Zeigern nicht finden kann. Er kann die Verwendung von Zeigern prüfen, wenn Sie in den Einstellungen zur Kompilierung die Option Bereichsprüfung markiert haben. Weitere Informationen dazu finden Sie im Handbuch 4th Dimension Designmodus.

Der Compiler analysiert während dem Kompilieren die Definitionen der in der Datenbank verwendeten Plug-In Befehle, z.B. Anzahl und Typ ihrer Parameter. Beim Typisieren treten keine Verwechslungen auf, wenn Ihre Aufrufe mit der Deklaration der Methode übereinstimmen.

Legen Sie Plug-Ins unter Windows in das Verzeichnis WIN4DX, auf Mac OS in den Ordner MAC4DX, und zwar an die von 4th Dimension zugelassene Stelle: Auf dieselbe Ebene wie die Datenbankstruktur, wie das ausführbare Programm (Windows) / in das Software Paket (MacOS), oder den aktiven 4D Ordner auf Ihrem Rechner. Weitere Informationen dazu finden Sie im Installationshandbuch 4D Produkte.

Der Compiler dupliziert diese Dateien nicht, prüft jedoch, ob die dazugehörigen Routinen korrekt deklariert sind.

Liegen Ihre Plug-Ins an anderer Stelle, fordert der Compiler Sie auf, diese während der Typisierung über den Öffnen-Dialog zu setzen.

• Plattformunabhängige Kompilierung unter Windows

Wollen Sie unter Windows eine Datenbank mit Plug-Ins kompilieren, die auf einer Mac OS Plattform mit 4th Dimension, 4D Client für Mac OS oder mit 4D Client für Mac OS und Windows laufen sollen, führen Sie folgende Schritte aus:

1. Installieren Sie die Mac OS Version des Plug-In auf Ihrem Macintosh-Rechner.

2. Übertragen Sie die Datei über das Hilfsprogramm "4D Transporter" auf Windows.

3. Erstellen Sie unter Windows einen neuen Ordner und nennen ihn Mac4DX.

4. Kopieren Sie die "transportierten" Dateien dieses Plug-In von Ihrem Macintosh-Rechner in den entsprechenden Ordner Ihres Windows-Rechners. Sie haben den Namen des Plug-In mit der Endung .4CX oder .4DX und .RSR.

5. Legen Sie diesen Ordner auf dieselbe Ebene wie den Ordner Win4DX der Datenbank.

• Plattformunabhängige Kompilierung auf Mac OS

Wollen Sie auf Mac OS eine Datenbank mit Plug-Ins kompilieren, die auf einer Windows Plattform mit 4th Dimension, 4D Client für Windows oder mit 4D Client für Mac OS und Windows laufen sollen, führen Sie folgende Schritte aus:

1. Kopieren Sie die Windows Dateien der Plug-Ins auf Ihren Macintosh-Rechner.

Das sind die Dateien mit dem Namen des Plug-In mit der Endung .4CX oder .4DX und .RSR.

2. Erstellen Sie auf Mac OS einen neuen Ordner mit Namen Win4DX.

3. Kopieren Sie die Windows Dateien des Plug-In in diesen Ordner.

4. Platzieren Sie diesen Ordner auf derselben Ebene wie den Ordner Mac4DX der Datenbank.

Bestimmte Plug-Ins, zum Beispiel 4D Write enthalten Befehle, die indirekt Befehle von 4th Dimension aufrufen.

Die Syntax für den 4D Write Befehl WR ON EVENT lautet:

Der letzte Parameter ist der Name der Methode, die Sie in 4th Dimension erstellt haben. Diese Methode ruft 4D Write immer auf, wenn das Ereignis empfangen wird. Es empfängt automatisch die nachfolgenden Parameter:

Der Compiler kann diese Parameter nur berücksichtigen, wenn sie entweder über eine Compiler Direktive oder durch ihre Verwendung in der Methode typisiert sind. Kommen sie in einem Prozess vor, muss ihre Verwendung so klar sein, dass sich der Typ eindeutig ableiten lässt.

Über Plug-In Befehle erstellte Variablen

Variablen, die über Plug-In Befehle erstellt wurden, kann der Compiler während der Kompilierung nur erkennen, wenn sie im Code der Datenbankstruktur deklariert wurden.

• Mac OS

Damit der Compiler diese Variablen erkennt, müssen Sie in der Strukturdatei Ihrer Datenbank eine Ressource erstellen, z.B. mit dem Ressourcen-Editor ResEdit®. Für Prozessvariablen muss es eine VAR# Ressource sein, für Interprozessvariablen eine VAR<> Ressource (drücken Sie für das Diamond-Zeichen die Kombination Wahltaste+V). Sie können die Variablen dann innerhalb dieser Ressourcen deklarieren.

• Windows

Damit der Compiler diese Variablen erkennt, müssen Sie zuvor die Ressource VAR# bzw VAR<> erstellt haben. Benötigt Ihre Datenbank diese Ressourcen, können Sie diese auf der Mac OS Plattform über einen Ressourcen-Editor, z.B. ResEdit® anlegen.

Hinweis: Weitere Informationen zum Bearbeiten von Plug-In Befehlen finden Sie im Kit 4D Plugin API.

Mit 4th Dimension und 4D Insider können Sie 4D Components erstellen und verwalten. 4D Components sind vergleichbar mit 4D Objekt Libraries, in denen jedem Objekt ein Attribut zugewiesen ist ("Private", "Protected" oder "Public"), das angibt, ob es sichtbar, änderbar, etc. ist. Weitere Informationen zu 4D Components finden Sie in der Dokumentation zu 4D Insider.

Entwickler von 4D Components sollten generell darauf achten, dass sich die Component kompilieren lässt und keine Konflikte verursacht. Dies lässt sich natürlich nie ganz ausschließen. Tritt beim Kompilieren ein Fehler auf, der von einem Objekt aus einer Component stammt, zeigt der Compiler je nach Objekteigenschaft folgende Information:

• "Private": Der Compiler zeigt nicht den Namen des entsprechenden Objekts an, sondern lediglich den Namen der 4D Component.

• "Protected" oder "Public": Der Compiler zeigt den Objektnamen an, wie für ein Objekt der Datenbank. (Standardverhalten).

Für lokale Variablen gelten alle bereits genannten Regeln. Wie für andere Variablen lässt sich der Datentyp nicht abändern, während eine Methode ausgeführt wird. Im folgenden sehen Sie zwei Vorgänge, die zu Datentypkonflikten führen können:

• Sie müssen aus bestimmten Gründen retypisieren. Hier helfen Zeiger, Datentypkonflikte zu vermeiden.

• Sie müssen Parameter über Indirektion ansprechen.

Eine Variable lässt sich nicht retypisieren. Sie können sich jedoch über Zeiger auf Variablen mit unterschiedlichen Datentypen beziehen.

Nehmen wir als Beispiel eine Funktion, die die Speichergrösse eines eindimensionalen Array zurückgibt. Das Ergebnis ist ein Wert vom Typ Zahl; davon ausgenommen sind Arrays vom Typ Text und vom Typ Bild. Hier richtet sich die Speichergrösse nach Werten, die sich nicht als Zahl ausdrücken lassen. Weitere Informationen dazu finden Sie im Abschnitt Arrays und Speicher.

Für Arrays vom Typ Text bzw. Bild ist das zurückgegebene Ergebnis eine Zeichenkette. Diese Funktion benötigt als Parameter einen Zeiger auf das Array, dessen Speichergröße wir wissen wollen.

Hierfür gibt es zwei Möglichkeiten:

• Sie arbeiten mit lokalen Variablen, ohne sich um die Datentypen zu kümmern; in diesem Fall läuft die Methode nur im interpretierten Modus.

• Sie verwenden Zeiger und arbeiten im interpretierten oder kompilierten Modus.

• Funktion MemSize, nur im interpretierten Modus (Beispiel für Mac OS)

   $Size:=Size of array($1->)
   $Type:=Type($1->)
   Case of
      :($Type=Real array)
         $0:=8+($Size*10)   ` $0 ist eine Zahl
         VarNum:=8+($Size*4)
      :($Type=Integer array)
         $0:=8+($Size*2)   
      :($Type=LongInt array)
         $0:=8+($Size*4)   
      :($Type=Date array)
         $0:=8+($Size*6)
      :($Type=Text array)
         $0:=String(8+($Size*4))+("+Sum of text lengths")   ` $0 is a Text
      :($Type=Picture array)
         $0:=String(8+($Size*4))+("+Sum of picture sizes")   ` $0 is a Text
      :($Type=Pointer array)
         $0:=8+($Size*16)   
      :($Type=Boolean array)
         $0:=8+($Size/8)   
   End case

In der obigen Methode ändert sich der Datentyp von $0 entsprechend auf den Wert von $1; von daher ist er nicht mit dem Compiler kompatibel.

• Funktion MemSize m interpretierten und kompilierten Modus (Beispiel für Mac OS)

Hier wird die Methode mit Zeigern geschrieben:

   $Size:=Size of array($1->)
   $Type:=Type($1->)
   VarNum:=0
   Case of
      :($Type=Real array)
         VarNum:=8+($Size*10)   ` VarNum ist eine Zahl
      :($Type=Integer array)
         VarNum:=8+($Size*2)
      :($Type=LongInt array)
         VarNum:=8+($Size*4)      
      :($Type=Date array)
         VarNum:=8+($Size*6)
      :($Type=Text array)
         VarText:=String(8+($Size*4))+("+Sum of text lengths") 
      :($Type=Picture array)
         VarText:=String(8+($Size*4))+("+Sum of picture sizes")
      :($Type=Pointer array)
         VarNum:=8+($Size*16)
      :($Type=Boolean array)
         VarNum:=8+($Size/8)
   End case
   If (VarNum#0)
      $0:=->VarNum
   Else
      $0:=->VarText
   End if

Die wichtigsten Unterschiede zwischen beiden Funktionen sind:

• Im ersten Fall ist das Funktionsergebnis die erwartete Variable,

• Im zweiten Fall ist das Funktionsergebnis ein Zeiger auf diese Variable. Sie dereferenzieren einfach Ihr Ergebnis.

Der Compiler verwaltet die Leistungsstärke und Flexibilität der Parameter Indirektion. Im interpretierten Modus können Sie frei wählen bei der Anzahl und den Datentypen der Parameter. Das gilt auch für den kompilierten Modus, vorausgesetzt, Sie verursachen keine Datentypkonflikte und verwenden nicht mehr Parameter, als Sie in der aufrufenden Methode übergeben haben.

Um Konflikte zu vermeiden, sollten Parameter, die über Indirektion angesprochen werden, alle vom selben Datentyp sein.

Die Indirektion funktioniert am besten, wenn Sie folgende Regel beachten: Werden nur einige der Parameter über Indirektion angesprochen, sollten Sie nach den fest vorgegebenen Parametern stehen

Innerhalb der Methode hat eine Indirektion das Format ${$i}, wobei $i eine numerische Variable ist, ${$i} der Parameter für die Indirektion.

Nehmen wir als Beispiel eine Funktion, die Werte hinzufügt und deren Summe in einem Format zurückgibt, das als Parameter übergeben wurde. Immer wenn diese Methode aufgerufen wird, kann die Anzahl der hinzugefügten Werte anders sein. Sie müssen die Werte als Parameter in der Methode übergeben, das Format als Zeichenkette. Die Anzahl der Werte kann von Aufruf zu Aufruf variieren. Die Funktion wird folgendermaßen aufgerufen:

   Result:=MySum("##0.00";125,2;33,5;24)

In diesem Fall erhält die aufrufende Methode den String "182.70", das ist die Summe der Zahlen im angegebenen Format. Die Parameter der Funktion müssen in der richtigen Reihenfolge übergeben wrden, d.h. zuerst das Format, dann die Werte.

Die Funktion mit Namen MySum lautet:

   $Sum:=0
   For($i;2;Count parameters)
      $Sum:=$Sum+${$i}
   End for
   $0:=String($Sum;$1)

Diese Funktion können Sie nun auf verschiedene Arten aufrufen:

   Result:=MySum("##0.00";125,2;33,5;24)
   Result:=MySum("000";1;18;4;23;17)

Analog zu anderen lokalen Variablen ist es nicht notwendig, generische Parameter über eine Compiler Direktive zu deklarieren. Bei Bedarf, d.h. bei Zweideutigkeit oder zur Optimierung erfolgt dies mit folgender Syntax:

   C_INTEGER(${4})

Dieser Befehl bedeutet, dass alle Parameter ab dem vierten (einschliesslich) über Indirektion angesprochen werden und vom Datentyp Ganzzahl sind. $1, $2 und $3 können einen beliebigen Datentyp haben. Verwenden Sie dagegen $2 über Indirektion, wird der generische Datentyp verwendet, d.h. Ganzzahl, auch wenn Sie dafür als Datentyp Zahl festgelegt hatten.

Hinweis: Der Compiler verwendet diesen Befehl während der Typisierung. Die Zahl in der Deklaration muss eine Konstante und nicht eine Variable sein.

Einige Variablen und Konstanten in 4th Dimension erhalten Datentyp und Kennung über den Compiler. Von daher können Sie mit diesen Variablen- bzw. Konstantennamen weder neue Variablen, Methoden noch Funktionen oder Plug-In Befehle erstellen. Sie können sie jedoch wie im interpretierten Modus verwenden und ihre Werte testen.

4th Dimension enthält folgende Systemvariablen:

Erstellen Sie in einem Bericht berechnete Spalten, legt 4th Dimension automatisch eine Variable C1 für die erste, C2 für die zweite, usw. an. Verwenden Sie diese Variablen in Methoden, bedenken Sie, dass C1, C2…Cn sich wie andere Variablen nicht retypisieren lassen.

Die vollständige Liste vordefinierter Konstanten in 4th Dimension finden Sie im Anhang dieses Handbuchs. 4D Konstanten erscheinen auch im Designmodus im Explorer.

Compiler Direktiven, Einzelheiten zur Syntax, Fehlermeldungen, Tipps zur Optimierung.