Richtlinien zur Typisierung

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

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:

und in derselben Anwendung an anderer Stelle:

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

Nehmen wir an, Sie schreiben:

und in derselben Anwendung an anderer Stelle:

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

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:

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:

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:

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

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

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:

und dann

Sie können jedoch in Methode M1 schreiben:

und in Methode M2:

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:

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:

Sie können jedoch in derselben Anwendung schreiben:

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:

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

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 oder die Anzahl der Dimensionen verändern. Sie befinden sich also in einer dieser Situationen.
Der Compiler generiert eine Fehlermeldung; die erforderliche Korrektur ist meist ganz offensichtlich. Beispiel für implizierte Retypisierung finden Sie im Abschnitt Einzelheiten zur Syntax.

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 4D deklarieren.  
Ein Array explizit deklarieren heißt, 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:

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 Abschnitt Compilermethoden für ... des Handbuchs 4D Designmodus.

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

4D Write Pro Bereiche sind immer Variablen vom Typ Objekt. Hier kann es keinen Typisierungskonflikt geben, außer der gleiche Variablenname wird noch in einem anderen Teil der Anwendung verwendet.

Diese Variablen sind in zwei Kategorien unterteilt:

• Einfache Variablen (eingebbare und nicht eingebbare 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 (DropDown Listen, Menüs/Dropdown Listen, rollbare Bereiche, PopUp-Menüs, Combo Boxen, Registerkarten und Spalten von Listboxen):
  Einige 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 TEXT, ARRAY BOOLEAN, etc.

Jede Listbox fügt mehrere Variablen in den Formularen hinzu. Der Standardtyp dieser Variablen richtet sich nach dem Typ der Listbox:

Sorgen Sie für die korrekte Identifizierung und Typisierung dieser Variablen und Arrays, um während dem Kompilieren Konflikte beim Generieren zu vermeiden.

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:

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:

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 Abschnitt Bereichsprüfung des Handbuchs 4D 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.

Stellen Sie sicher, dass Ihre Plug-Ins im Ordner PlugIns installiert sind und zwar an die von 4D zugelassene Stelle: Neben die Strukturdatei der Datenbank, neben das ausführbare Programm (Windows) / in das Software Paket (Mac OS). Zur Wahrung der Kompatibilität kann auch noch der Ordner Win4DX bzw. Mac4DX neben der Strukturdatei verwendet werden. Weitere Informationen dazu finden Sie im 4D Installationshandbuch.
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.

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(area;event;eventMethod)

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:

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.

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 interpretierte als kompilierte Komponenten verwenden. Sie können in derselben 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 Komponenten aufruft. Sonst erscheint beim Wählen des Menübefehls Compiler eine Warnung und Kompilieren ist nicht möglich.
Ein Namenskonflikt kann auftreten, wenn eine gemeinsam genutzte Projektmethode in einer Komponente 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 Komponente 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 dazu finden Sie im Kapitel 4D Komponenten entwickeln und installieren des Handbuchs 4D Designmodus.

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

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 im interpretierten und kompilierten Modus (Beispiel für Mac OS)
Hier wird die Methode mit Zeigern geschrieben:

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:

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:

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

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:

Dieser Befehl bedeutet, dass alle Parameter ab dem vierten (einschließlich) über Indirektion angesprochen werden und vom Datentyp Lange 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. Lange 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 keine Variable sein.

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.

4D enthält folgende Systemvariablen:

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.

Die vollständige Liste vordefinierter Konstanten in 4D finden Sie unter Konstantenthemen. 4D Konstanten erscheinen auch im Designmodus im Explorer (siehe Seite Konstanten im Handbuch 4D Designmodus).