Richtlinien zur Typisierung

4D - Documentation   Français   English   German   English   4D Programmiersprache, Befehle nach Themen   4D Programmiersprache, Befehle alphabetisch   4D Programmiersprache, Konstanten nach Themen   Back   Previous   Next

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.

Konflikt zwischen zwei Verwendungen

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.

Konflikt zwischen Verwendung und Compiler Direktive

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

Konflikt durch implizierte Retypisierung

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

Konflikt zwischen zwei Compiler Direktiven

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.

Anmerkung zu lokalen Variablen

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 Arrays


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.

Datentypen bei Elementen im Array verändern

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.

Dimensionen eines Array verändern

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.

Arrays mit festen Strings

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.

Implizierte erneute Typisierung

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.

Lokale Arrays

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 typisieren


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 4D Designmodus.

Variablen, die im Formular standardmäßig als Zahl gelten

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.

Variable Diagramm

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.

Variable Plug-In Bereich

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.

Variablen, die im Formular standardmäßig als Text gelten

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....

Zeiger


Enthält Ihre Datenbank Zeiger, nutzen Sie die Vorteile eines leistungsstarken und ausgeklügelten Werkzeugs von 4D. 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.

Plug-In Befehle


Allgemein

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 4D 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.

Plug-In Befehle mit spezifischen Parametern

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

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

WR ON EVENT(Bereich;Ereignis;EreignisMethode)

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

ParameterTypBeschreibung
$0Lange GanzzahlZurückgegebene Funktion
$1Lange Ganzzahl4D Write Bereich
$2Lange GanzzahlUmschalttaste
$3Lange GanzzahlAlt-Taste (Windows); Wahltaste (Mac OS)
$4Lange GanzzahlStrg-Taste (Windows), Befehlstaste (Mac OS)
$5Lange GanzzahlEreignistyp
$6 Lange GanzzahlWert richtet sich nach Parameter des Ereignisses

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.

4D Komponenten


Mit 4D können Sie 4D Komponenten erstellen und verwalten. Eine 4D Komponente besteht aus einer Reihe von 4D Objekten, mit einer oder mehreren Funktionalitäten, die sich in verschiedenen Datenbanken, genannt Host Datenbank installieren lässt.

Eine Host Datenbank kann im interpretierten Modus sowohl interpre-tierte als kompilierte Komponenten verwenden. Sie können in dersel-ben Host Datenbank interpretierte und kompilierte Komponenten installieren.

Dagegen kann eine Host Datenbank im kompilierten Modus keine interpretierten Komponenten verwenden. Hier sind nur kompilierte Komponenten möglich.

Eine interpretierte Datenbank mit interpretierten Komponenten ist kompilierbar, wenn sie keine Methoden von interpretierten Kompo-nenten aufruft. Sonst erscheint beim Wählen des Menübefehls Compi-ler eine Warnung und Kompilieren ist nicht möglich.

Ein Namenskonflikt kann auftreten, wenn eine gemeinsam genutzte Projektmethode in einer Komponenten denselben Namen wie eine Projektmethode der Host Datenbank hat. In diesem Fall wird beim Ausführen des Code in der Host Datenbank die Methode der Host Datenbank aufgerufen. Es ist also möglich, die Methode einer Kompo-nente mit einer eigenen Methode zu verdecken, z.B. um eine andere Funktionalität zu erhalten

Wird der Code in der Komponente ausgeführt, wird die Methode der Komponente aufgerufen. Diese Überdeckung wird in einer Warnung im Kompilierungsereignis der Host Datenbank angezeigt.

Nutzen zwei Komponenten gemeinsam Methoden mit demselben Namen, wird beim Kompilieren der Host Datenbank ein Fehler erzeugt.

Weitere Informationen zu 4D Komponenten finden Sie im Handbuch 4D Designmodus.

Lokale Variablen $0…$N und Parameterübergabe


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.

Zeiger zur Vermeidung von Retypisieren verwenden

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öße 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öße 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.

Parameter Indirektion

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.

Reservierte Variablen und Konstanten


Einige Variablen und Konstanten in 4D 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.

Systemvariablen

4D enthält folgende Systemvariablen:

VariableTyp
OKLange Ganzzahl
DocumentString (255)
FldDelimitLange Ganzzahl
RecDelimitLange Ganzzahl
ErrorLange Ganzzahl
MouseDownLange Ganzzahl
KeyCodeLange Ganzzahl
ModifiersLange Ganzzahl
MouseXLange Ganzzahl
MouseYLange Ganzzahl
MouseProcLange Ganzzahl

Variablen im Schnellbericht

Erstellen Sie in einem Bericht berechnete Spalten, legt 4D 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.

Vordefinierte Konstanten in 4D

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

Referenz

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


4D - Documentation   Français   English   German   English   4D Programmiersprache, Befehle nach Themen   4D Programmiersprache, Befehle alphabetisch   4D Programmiersprache, Konstanten nach Themen   Back   Previous   Next