Überholte und entfernte Funktionalitäten

Seit 30 Jahren ist unser Hauptziel die laufende Verbesserung der 4D Produktreihe, d.h. neue Konzepte und Technologien zu verwenden und dabei die Kompatibilität der 4D Programme zu gewährleisten. Langjährige Nutzer von 4D wissen, dass wir immer eine Menge Arbeit in Kompatibilität stecken. So gibt es auf der ganzen Welt 4D Anwendungen, die schon vor Jahrzehnten erstellt wurden, mit heute veralteten 4D Versionen und auf alten Betriebssystemen, die aber mit den neuesten Produkt-Releases immer noch laufen.

Es ist jedoch nicht immer möglich, alte und neue Technologien miteinander zu vermischen, denn

• 4D muss neue Technologien, neue APIs und neue Paradigmen für Entwickler herausbringen
• Betriebssysteme ändern sich täglich und unterstützen manchmal ihre eigenen alten APIs nicht mehr

Aus diesem Grund muss auch 4D bestimmte Befehle und Funktionalitäten als überholt deklarieren, was bedeutet, dass sie in einer zukünftigen Hauptversion entfernt werden.

Hier informieren wir Entwickler, was überholt ist und was sie stattdessen verwenden können. So ist es um einiges leichter, die Änderungen in den eigenen Code zu übernehmen: Es besteht keine Eile, kein Druck und der Entwickler hat genügend Zeit für notwendige Änderungen.

 Die Einträge in der Spalte “Status” bedeuten folgendes:

• Entfernt: Ist in der aktuellen Version bzw. der angegebenen Version nicht mehr verfügbar
• Überholt: Sollte nicht mehr verwendet werden und wird in einer zukünftigen Hauptversion entfernt
• OS: Hängt von offiziell überholten Technologien des Betriebssystems ab (z.B.: PICT Format). Das ist derselbe Status wie Überholt, ein Betriebssystem kann jedoch eine Funktionalität entfernen, bevor wir das tun.

Jeder überholte Befehl erhält die Vorsilbe _o_ und ist in 4D Listen (Code-Editor, type-ahead Funktion, etc.) nicht verfügbar. Überholte (oder veraltete) Befehle werden nicht aus vorhandenem Code entfernt und funktionieren wie gewohnt, solange sie noch unterstützt werden. Sie lassen sich weiterhin (auch wenn wir davon abraten) mit der Vorsilbe _o_  im Namen in einer Methode hinzufügen und werden korrekt interpretiert.

Diese Befehle in alphabetischer Reihenfolge finden Sie im Anhang Überholte Befehle des Handbuchs 4D Programmiersprache.

Die folgenden Befehle waren bisher veraltet. Sie wurden in 4Dv17 R5 entfernt und dürfen in Ihrem Code nicht mehr verwendet werden. Beim Aufrufen lösen Sie den Fehler 33 aus: "Befehl oder Funktion ist nicht vorhanden".

Warnung: Die Syntaxprüfung oder Features zum Kompilieren können keine Aufrufe von entfernten Befehlen herausfinden. Sie müssen Ihren Code überprüfen, um sicherzustellen, dass er keine Aufrufe entfernter Befehle enthält. 

Der Projektmodus ist eine wichtige Evolution in der Architektur von 4D Datenbanken. Da er auf den neuesten Software-Anforderungen für die Oberfläche und aktuellen Technologien basiert, unterstützt er einige veraltete Features nicht (siehe nachfolgende Tabellen). Solche Features sollten Sie zur besseren Anpassung an die zukünftige Projekt-Architektur nicht mehr verwenden. 

Ausführliche Informationen zur Projekt-Architektur in 4D finden Sie im Dokument 4D Projects unter developer.4d.com. 4D bietet ein automatisches Export Tool, um .4db Anwendungen in Projekte zu konvertieren. Veraltete Features werden während dem Export automatisch konvertiert, entfernt oder erzeugen Fehler (siehe Anwendungen in Projekte umwandeln).

Folgende Formularobjekte und Eigenschaften erfüllen nicht die Anforderungen für aktuelle Oberflächen und sind jetzt überholt. Dynamische Formulare unterstützen sie nicht und können im Konvertierungsprotokoll eine Warnung oder einen Fehler generieren. (siehe Kommentar).  

Folgende Einstellungen für Felder sind überholt und werden bearbeitet oder zeigen im Konvertierungsprotokoll einen Fehler (siehe Kommentar).  

Folgende Editoren und Features der Toolbox sind überholt und werden in Projekten nicht unterstützt:

Projekte unterstützen keine bisherigen Einstellungen zur Kompatibilität. Sie werden beim Export in ein Projekt wie für eine neue Anwendung zurückgesetzt. Nutzt Ihre Anwendung noch alte Einstellungen für Kompatibilität, sollten Sie entsprechende Anpassungen vornehmen. 

Wir raten dringend, dazu die Blogs unter series of blog posts devoted to how to get rid of compatibility settings zu lesen. 

Ab 4D v17 R5 werden 32-bit Versionen von 4D und 4D Server weder hergestellt noch ausgeliefert. Nur 64-bit Versionen sind verfügbar, so dass 4D Applikationen die Vorteile dieses leistungsstarken Architektur vollständig nutzen können. 

64-bit Versionen unterstützen zwar die meisten der bisherigen 4D Funktionalitäten, orientieren sich aber an den neuesten Technologien und unterstützen nicht solche, die schon in vorigen Versionen veraltet waren. Beim Updaten von Anwendungen, die in 32-bit entwickelt wurden, sind evtl. einige Anpassungen erforderlich. Weitere Informationen zum Updaten Ihrer Anwendungen finden Sie auf der Seite Von 32-bit Versionen auf 64-bit Versionen wechseln des Handbuchs Konvertierung in v18.

XSLT ist in 4D nicht mehr verfügbar. Beim Aufrufen eines XSLT Befehls erscheint der Fehler 33 "Befehl oder Funktion ist nicht vorhanden".

Für Kunden, die noch XSLT in 4D verwenden, bieten wir noch die Nutzung der PHP XSL library. Sie enthält ein verständliches API, mit dem Sie alle erforderlichen Operationen zum Ersetzen der XSL Transformation durchführen können. Damit können Sie auch mühelos die entfernten Befehle _o_XSLT APPLY TRANSFORMATION, _o_XSLT SET PARAMETER und _o_XSLT GET ERROR ersetzen. Ausführliche Informationen zur Verwendung von PHP XSL anstelle der überholten XSLT 4D Befehle finden Sie unter: Download XSLT with PHP technical document (PDF).

Wir empfehlen außerdem die Nutzung von 4D TAGS, wenn HTML Seiten dynamisch generiert werden sollen. Denn in den meisten Fällen lässt sich HTML Code leichter als unformatierter Text verwalten. Weitere Informationen dazu finden Sie unter dem Befehl PROCESS 4D TAGS.

In 4D v17 R5 wurde die Kompatibilitäts-Unterstützung von QuickTime (über Datenbankparameter) entfernt. Codecs für Bilder in einem Format, das QuickTime erfordert, werden auf macOS und Windows nicht mehr unterstützt.

Ab v18 werden Datenfelder vom Typ Fließkomma in 4D Anwendungen nicht mehr unterstützt. Diesen Datenfeldtyp hat bisher nur die SQL Engine von 4D genutzt. Hat Ihre Anwendung den Typ Fließkomma verwendet, wird er beim Öffnen der Anwendung in v18 automatisch in den Typ Zahl konvertiert. Vorhandene Daten werden nicht konvertiert, außer Sie komprimieren die Daten oder sichern Datensätze erneut.

Die Unterstützung des ASCII Modus, auch Nicht-Unicode Modus genannt, wurde in 4D V17 R5 und höher entfernt. Beim Öffnen einer konvertierten Anwendung, die nicht auf Unicode gesetzt ist, zeigt 4D folgende Meldung: 

Diese Meldung erscheint bei jedem Starten, wenn die Option Unicode Modus auf der Seite "Kompatibilität" der Datenbank-Einstellungen nicht markiert ist. 
4D Entwickler müssen in konvertierten Strukturen den Unicode Modus aktivieren. Weitere Hinweise dazu finden sie im PDF Dokument 4D v14 Konvertierung.

Ab 4D v17 R5 wird das PICT Format (von Apple seit 2005 als veraltet deklariert) nicht mehr unterstützt, d.h. Bilder im PICT Format lassen sich überhaupt nicht mehr darstellen, sie müssen konvertiert werden. Mit dem Befehl GET PICTURE FORMATS können Sie Bilder im PICT Format in Ihren Datendateien finden und herausfiltern.

Ab 4D v17 R5 wird der Schlüssel DatabaseOutsidePackage in der info.plist ignoriert. Dieser spezifische Vertriebsmodus für 4D Anwendungen im Einzelplatz mit einkompilierter Volume Desktop auf der Mac Plattform wird nicht mehr unterstützt.

Ab 4D v17 R4 unterstützt 4D unter Windows nicht mehr spezifisch Oberflächen von rechts-nach-links. Die dazugehörigen Optionen in den Datenbank- oder Formulareigenschaften wurden entfernt. In konvertierten Anwendungen werden Einstellungen für rechts-nach-links im laufenden Betrieb ignoriert.

Ab 4D v17 R4 sind Benutzerformulare überholt. Für anpassbare Benutzeroberflächen empfehlen wir jetzt, dynamische Formulare zu verwenden (siehe Dynamische Formulare des Handbuchs 4D Designmodus). Alle Befehle im Kapitel "Benutzerformulare" sind überholt.

Zur Wahrung der Kompatibilität werden Benutzerformulare noch unterstützt, sie sollten aber nicht mehr verwendet werden. Denn dieses Feature wird in zukünftigen Releases entfernt.

4D Mobile ist ab 4D v18 überholt und sollte nicht mehr verwendet werden. Der Zugriff auf 4D Daten über REST Anfragen wird jetzt über ORDA Technologie und den 4D REST Server unterstützt. 

In früheren 4D Versionen hat der Web Server automatisch den Wert von Variablen, die über ein Web Formular oder eine URL gesendet wurden, in 4D Variablen kopiert, wenn sie denselben Namen hatten.
Dieses Prinzip wird aus Sicherheitsgründen in 4D v14 nicht beibehalten, d.h. der Wert von Web Variablen wird nicht mehr automatisch 4D Variablen zugewiesen. Um über POST oder GET gesendete Variablen zu finden, müssen Sie ausschließlich den Befehl WEB GET VARIABLES verwenden.
Um per POST übertragene Dateien zu erhalten, müssen Sie den Befehl WEB GET BODY PART bzw. WEB Get body part count verwenden.

Hinweis: Die dynamische Zuweisung ist in 4D Anwendungen, die mit v13.4 oder höher erstellt wurden, standardmäßig deaktiviert.

Die bisherige Funktionsweise wird zur Wahrung der Kompatibilität standardmäßig in Anwendungen beibehalten, die mit einer Version älter als 13.4 erstellt wurden. Sie können bei Bedarf in den Datenbank-Eigenschaften auf der Seite Kompatibilität die Option Automatische Zuweisung von Variablen deaktivieren.

Da diese Funktionsweise überholt und unsicher ist, empfehlen wir dringend, diese Option in konvertierten Anwendungen zu deaktivieren (und Ihren Code bei Bedarf anzupassen).

4D warnt Entwickler schon seit einigen Hauptversionen (Major Releases) davor, Untertabellen zu verwenden. Schon seit 4D v11 lässt sich kein Datenfeld vom Typ Untertabelle mehr anlegen. Unterdatensätze haben einige bekannte Einschränkungen. Sie werden z.B. immer in den Speicher geladen und nicht von den Befehlen SEND RECORD oder DUPLICATE RECORD verwaltet.

Wir planen vorerst nicht, die Unterstützung von Untertabellen zu entfernen. Entwickler sollten aber auf alle Fälle ihre Untertabellen in reguläre N-> Tabellen umwandeln, da sie in einer zukünftigen 4D Hauptversion entfernt werden.

Im allgemeinen gibt es zwei Vorgehensweisen zum Entfernen von Untertabellen. Hier ein ein kurzer Überblick:

• Vor der Konvertierung einer Struktur älter als v11: Erstellen Sie in 2004 eine geeignete Viele-Tabelle und das Feld ID in einer 1 Tabelle (falls noch nicht vorhanden). Ändern Sie dann den Code an den erforderlichen Stellen (siehe unten).
• Nach der Konvertierung: In diesem Fall hat 4D über eine spezielle Verknüpfung die Untertabelle durch eine Viele-Tabelle ersetzt. So kann die Programmiersprache übergangsweise mit der Unterauswahl und den Unterdatensätzen arbeiten. Der 4D Entwickler muss diese spezielle Verknüpfung entfernen, durch eine normale Verknüpfung ersetzen und den Code an den erforderlichen Stellen ändern (siehe unten).

“den Code an den erforderlichen Stellen ändern” bedeutet im Einzelnen:

• Neue Formulare anlegen, eingebundene Formulare aktualisieren
• In den Methoden (Projekt, Formular, Objekt, etc.):
  
  • Alle Befehle des Kapitels “Untertabellen” mit dem entsprechenden Befehl Selection oder Record ersetzen. Beispiel _o_CREATE SUBRECORD mit CREATE RECORD ersetzen, die ID Felder füllen
  • Falls erforderlich, die Viele-Datensätze explizit laden

Hinweis: Ab 4D v14 R3 können Sie dem speziellen Feld "id_added_by_converter" selbst Werte zuweisen. Dieses Feld fügt 4D automatisch hinzu, wenn eine Anwendung mit Untertabellen konvertiert wird. So können Sie die spezielle Verknüpfung "Untertabelle Verknüpfung" beibehalten und verknüpfte Datensätze ändern oder hinzufügen, als ob sie normale Datensätze wären und müssen nicht mehr überholte Befehle wie _o_CREATE SUBRECORD verwenden. Sind dann all Ihre Methoden aktualisiert, können Sie diese spezielle Verknüpfung durch eine reguläre Verknüpfung ersetzen, ohne Ihren Code zu verändern.

QuickDraw Schriften, wie z.B. Geneva, Chicago sind überholt und Sie sollten auch nicht mehr ID Nummern für Schriften verwenden.
Zur Wahrung der Kompatibilität ist die Funktion _o_Font name noch verfügbar, sie wird aber in nachfolgenden Versionen entfernt. Der Befehl OBJECT SET FONT akzeptiert jetzt nur Schriftnamen.

Es gibt zwei Arten: Plug-Ins, die das neue Plug-In API nutzen und solche, die noch das alte mit QuickDraw nutzen.

Für Plug-Ins mit der alten Toolbox (mit QuickDraw) gilt folgendes: Zur Wahrung der Kompatibilität wird das Zeichnen/Rendering nicht mehr – wie in früheren Versionen – direkt in einem QuickDraw Port ausgeführt, sondern über einen GWorld QuickDraw offscreen Bereich, speziell für dieses Plug-Ins.

Deshalb müssen Sie ein paar Regeln beachten, insbesondere dass Plug-Ins nicht den aktuellen Port verändern dürfen, der vom Container gesetzt wird (Formularobjekt).

Für Plug-Ins mit der neuen Toolbox gilt folgendes: Es wird nur die neue Toolbox verwendet und nicht QuickDraw. Ausführliche Informationen finden Sie unter https://github.com/4D/4D-Plugin-SDK)

Ab 4D v16 R6 sind auf Mac OS 9 basierende APIs zur Datei- und Ordnerverwaltung überholt. Diese APIs sind bei Apple schon seit längerer Zeit überholt.

4D Befehle, die auf den alten APIs basieren, wurden entsprechend umbenannt: _o_Document type, _o_Document creator, _o_SET DOCUMENT TYPE, _o_SET DOCUMENT CREATOR und _o_MAP FILE TYPES. Diese Befehle werden zur Wahrung der Kompatibilität beibehalten. Sie sind jedoch überholt und sollten nicht mehr verwendet werden. 4D enthält zwei neue Befehle zum Verwalten von Pfadnamen und Dateiendungen: Path to object und Object to path.

Standardaktionen wurden in 4D v16 R3 intern umgestaltet. Sie basieren jetzt auf Stringmustern und unterstützen Parameter. Weitere Informationen dazu finden Sie im Abschnitt Standardaktionen.

In Ihren konvertierten Anwendungen werden Standardaktionen transparent an das neue Design angepasst. In der 4D Programmiersprache basierten Standardaktionen bisher auf Code-Werten. Dieses Prinzip ist überholt und sollte nicht mehr eingesetzt werden:

• Die auf Code basierenden Standardaktionen vom Typ Text unter dem Konstantenthema Standardaktion (bisheriger Name "Textwerte für zugeordnete Standardaktionen") sind überholt und mit der Vorsilbe "_o_" gekennzeichnet. Sie sollten nicht mehr verwendet werden.
• Das gesamte Konstantenthema Zugewiesene Standardaktion ist überholt.
• Die Funktion _o_OBJECT Get action (die Code zurückgibt) ist überholt und wurde durch die aktualisierte Funktion OBJECT Get action ersetzt (die einen Namen zurückgibt).

Dies ist eine weitere alte Mac OS Technologie, die seit Mac OS X 10.4 überholt ist (Tiger, 2005). Ressourcen dienten zum Speichern von Strukturdaten, wie Text und Strings zur Lokalisierung, Icons, etc. Im Grunde genommen sind aber nicht die Ressourcen ansich überholt, sondern vielmehr die Unterstützung einer eigenen Datei auf der Festplatte, auch bekannt als Resource Fork. Sie ist Teil des Mac OS Dateisystems, und Apple hat seit Einführung von OS X die Unterstützung dieser Datei eingestellt, da sie mit anderen Dateisystemen, wie Unix oder Windows, nicht kompatibel ist und beim Übertragen von Dateien über das Netzwerk eine Menge Probleme verursachte.

Unter Windows wird dieser Mechanismus emuliert und Mac Ressourcen liegen in einer .RSR Datei.

Wir raten jedoch davon ab, diesen alten Mechanismus weiter zu verwenden - auch wenn es noch APIs zum Verwalten dieser Ressourcen gibt (und Mac OS in Data Forks gespeicherte Ressourcen transparent verwaltet). Dafür gibt es folgende Gründe:

• Text und Strings sind in Mac-Roman. Folglich können Sie Text in Unicode nicht in Ressourcen vom Typ TEXT oder STR# speichern
• PICT Ressourcen speichern PICTs: Sie sind veraltet, unterstützen keine Transparenz, etc. (siehe Abschnitt oben Bilder in PICT Format)
• Anzahl und Größe der Ressourcen sind begrenzt (bis zu 2700 Ressourcen oder 16 MB)

Befehle, die Ressourcen schreiben oder erstellen, werden nicht mehr unterstützt.

Die meisten 4D Applikationen, die Ressourcen nutzen, verwenden String Listen, d.h. ‘STR#’ Ressourcen. 4D bietet Tools, um einfach von STR# zu XLIFF zu wechseln:

• Die Komponente 4D Pop kann die XLIFF Dateien automatisch erstellen, d.h. den Inhalt von STR# lesen und übertragen.
• Alle Routinen und Ausdrücke, die sich auf STR# beziehen, funktionieren ohne Änderung mit XLIFF. Ist die Bezeichnung einer Schaltfläche oder eines Menüs z.B. “:15000,3” (was heißt “erhalte den dritten Eintrag der STR# ID 15000”), lädt 4D die entsprechende XLIFF Datei (sofern vorhanden).

Für andere Arten von Ressourcen gilt folgendes:

• Setzen Sie Ressourcen innerhalb des Ordners in getrennte Dateien und erstellen Sie bei Bedarf Unterverzeichnisse:
• Sichern Sie 'TEXT' Ressourcen in XLIFF oder .txt Dateien
• Sichern Sie 'PICT' Ressourcen in eigene Dateien, getrennt nach .jpg/.png/etc.
• Sichern Sie 'PICT' + MASK’ Ressourcen als .png Dateien
• Verwenden Sie (auf Mac) icns anstelle von ICON oder farbigen Icons
• Sichern Sie private Ressourcen in passender Form, also z.B. als binäre Datei mit spezifischer Endung

• Verwenden Sie den Ordner “Resources” zum Speichern Ihrer Ressourcen. Verwenden Sie Get 4D folder(Current resources folder), um den übergeordneten Pfad zu Ihren Ressourcen dynamisch zu erhalten.

Das Verändern der CPU Priorität ist jetzt eine überholte Einstellung. Da die Speicherverwaltung für 4D Applikationen im Laufe der Versionen optimiert wurde, muss die Standardeinstellung nicht mehr verändert werden, dies kann u.U. sogar kontraproduktiv sein. Es gibt folgende Anpassungen:

• Der Bereich "CPU Priorität" in den Datenbank-Eigenschaften auf der Seite "Algemein" erscheint jetzt nur in konvertierten Anwendungen, wo ein eigener Wert gesetzt wurde. Wird er angezeigt, empfehlen wir, auf die Schaltfläche Standardeinstellungen zu klicken, um diese Parameter zurückzusetzen und aus dem Dialogfenster zu entfernen.
• In 4D v16 R2 wurden die überholten Selektoren des Befehls SET DATABASE PARAMETER umbenannt (_o_4D Remote mode scheduler, _o_4D Local mode scheduler und _o_4D Server scheduler) und dürfen nicht mehr verwendet werden.