Überholte und entfernte Funktionalitäten    

Seit über 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.

Erläuterung der Werte für die Spalte "Status":

• Entfernt: Nicht mehr verfügbar in der aktuellen Version (oder der angegebenen Version).
• Überholt: Sollte nicht mehr verwendet werden und wird in einer zukünftigen Hauptversion entfernt werden.
• OS: Hängt von offiziell überholten OS-Technologien ab (z. B.: PICT-Format). Der Status ist derselbe wie "Veraltet", aber ein OS könnte die Unterstützung vor uns entfernen.

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.

Ab 4D v20 ist die Übereinstimmung Ihres Datenbankcodes mit der Objektnotation obligatorisch. Wenn Sie versuchen, eine Datenbank zu konvertieren, in der die Option Objektnotation für den Zugriff auf Objekteigenschaften verwenden noch nicht aktiviert war (Kompatibilitätsmodus, siehe Seite Kompatibilität), zeigt 4D ein Dialogfenster an, in dem Sie die Option vorübergehend aktivieren können, um die Datenbank öffnen zu können. Sie müssen die Option immer noch explizit aktivieren, um sie dauerhaft zuzulassen -- es wird jedoch empfohlen, die Kompatibilität der Applikation vorher mit dem MSC zu überprüfen. 

Wenn Sie auf Abbrechen klicken oder wenn die Datenbank den Zugriff auf den Entwicklungsmodus nicht zulässt (kompilierte Datenbank, kein Zugriff im Entwurf...), wird der Fehler -10537 erzeugt und die Datenbank wird nicht geöffnet. 

Hinweis: Der Kompatibilitätsmodus war nur in binären Datenbanken verfügbar. 

Der PDFCreator Treiber ist ab 4D v20 überholt. Windows 10 und höhere Versionen enthalten einen nativen PDF-Treiber. Die Konstante PDFCreator Druckername wurde umbenannt in _o_PDFCreator Printer name.

Several PHP modules have been removed from the included PHP interpreter in 4D v20, most of them because they are no longer needed or deprecated: DOM (Document Object Model), Iconv, LibXML, LibXSLT, SimpleXML, GD (Graphics Draw) Library, XML (eXtensible Markup Language), XMLreader, XMLwriter, WDDX (Web Distributed Data eXchange), Zlib, Zip. If your application was using a removed module, you might need to use relevant 4D commands or an external FastCGI-php interpreter. For more information, please refer to the PHP modules support section. 

Seit 4D v19 R4 ist aufgrund der Unterstützung des ternären Operators der Doppelpunkt ":" in Variablen-, Feld-, Konstanten-, Funktions-, Plugin- und Projektmethodennamen nicht mehr erlaubt.

Ab 4D v19 ist das 4D ODBC Pro Plug-in nicht mehr auf allen Plattformen verfügbar. Wir empfehlen, den eingebauten ODBC/SQL Pass-Through (siehe SQL LOGIN und Einführung in SQL Befehle) oder die 4D REST API zu verwenden, um ODBC/SQL Konnektivitätsfunktionen zu handhaben.  

Ab 4D v19 ist das 4D for OCI Plug-in nicht mehr unter macOS verfügbar. Wir empfehlen, den eingebauten ODBC/SQL Pass-Through (siehe SQL LOGIN und Einführung in SQL Befehle) oder die 4D REST API zu verwenden, um Konnektivitätsfunktionen auf dieser Plattform zu handhaben.  

Ab 4D v19 ist der 4D ODBC Treiber unter macOS nicht mehr verfügbar. Wir empfehlen die Verwendung des 4D REST API für den externen Datenzugriff auf diese Plattform. 

Die Speicheroption Außerhalb der Datendatei wird für Felder vom Typ Objekt nicht mehr unterstützt (siehe Speichern im Datensatz, in der Datendatei, außerhalb der Datendatei). Wenn diese Option für ein Objektfeld ausgewählt wurde, wird es automatisch in In Datendatei konvertiert und für neue Datensätze verwendet. Vorhandene Daten in Objektfeldern werden beim Speichern des übergeordneten Datensatzes transparent an der neuen Position neu geschrieben. Um zu erzwingen, dass alle Datensätze auf einmal umgeschrieben werden, können Sie die Datendatei mit der Option "Datensätze aktualisieren" verdichten.

Nach jahrelangem Einsatz ist es an der Zeit, sich von ihnen zu verabschieden: Interprozessvariablen sind jetzt überholt. Die Verwendung von Interprozess-Variablen wird in 4D Projekten nicht empfohlen, da sie von präemptiven Prozessen nicht zur Verfügung stehen und nicht für den Umgang mit komplexen Werten wie Arrays, Objekten oder Collections (wenn sie nicht gemeinsam genutzt werden) von mehreren Prozessen gleichzeitig geeignet sind. Schließlich neigen sie dazu, den Code weniger wartbar zu machen. Um Objekt- und Collection-Werte zwischen Prozessen auszutauschen, empfehlen wir dringend die Verwendung von shared Objects und Collections und/oder des Befehls Storage.

Ab 4D Write Pro v19 R4 können Sie Zeilenumbrüche verarbeiten. Um Verwechslungen mit Absatz- und Tabellenumbrüchen zu vermeiden, werden alle Umbrüche jetzt über spezielle Konstanten und Standardaktionen behandelt (siehe 4D Write Pro Attribute und 4D Write Pro Standardaktionen verwenden). Die bisherige generische Konstante (_o_wk page break inside) und die Standardaktion (avoidPageBreakInsideEnabled) sind überholt und werden nur noch zur Wahrung der Kompatibilität unterstützt.

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.

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.

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