Änderungen in der Produktreihe v17

Ab 4D v16 R5 ist 4D Windows Server 32-bit überholt. Diese Version basiert auf Komponenten und veralteten Libraries, die nicht mehr unterstützt werden. In neuen Major Releases ist nur 4D Windows Server 64-bit verfügbar.

64-bit Versionen verwenden aktuelle Technologien und unterstützen keine Technologien, die in vorigen 4D Versionen als überholt deklariert wurden. Die vollständige Liste der nicht mehr unterstützten Funktionen in der 64-bit Produktreihe finden Sie im Abschnitt Übersicht dieses Handbuchs.

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

Die XSLT Sprache, inspiriert durch funktionelle Programmierkonzepte, wandelt XML Daten in ein anderes Format um, also z.B. in XML, HTML. Alle gängigen Web Browser sowie 4D Software haben die XSLT 1.0 Spezifikation implementiert.

Heutzutage geht der XSLT Trend wieder zurück, da Entwickler die Verwendung und Fehlersuche schwierig finden. Deshalb haben wir beschlossen, das Feature XSL Transformation nicht mehr für 4D 64-bit Versionen zu entwickeln. Jedoch bieten wir unseren Kunden, die noch XSLT in 4D verwenden, 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 Befehle _o_XSLT APPLY TRANSFORMATION, _o_XSLT SET PARAMETER und _o_XSLT GET ERROR ersetzen, nachdem sie entfernt wurden. 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 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.

Hinweis: Trends der XSLT Suche in Google: http://www.google.com/trends/explore#q=xslt       

Zur Wahrung der Kompatibilität werden XSL Transformationen in 4D noch unterstützt. Wir raten jedoch von einer weiteren Verwendung ab. Die Bearbeitung von XSLT wird in zukünftigen 4D Releases entfernt.

Hinweis zu 64-bit Versionen: XSLT ist in 4D 64-bit (OS X und Windows) und in 4D Server 64-bit für OS X nicht verfügbar. Deshalb generiert die Applikation beim Aufrufen eines XSLT Befehls in diesen Kontexten den Fehler 33 "Befehl oder Funktion ist nicht vorhanden".

Das PICT Format wird in kommenden Hauptversionen (Major Releases) von 4D nicht mehr unterstützt und darf in 4D nicht mehr verwendet werden. Mit dem Befehl GET PICTURE FORMATS können Sie Bilder im PICT Format in Ihren Datendateien finden und herausfiltern.

Hinweis: Apple hat das "PICT" Format für Mac schon seit einigen Mac OS Versionen als veraltet deklariert (siehe Beschreibung des PICT Format in Wikipedia).

Das ‘PICT’ Format ist ein sehr altes Mac Format. Vor v11 hat 4D alle Bilder in diesem Format gespeichert, selbst für Windows. PICT ist veraltet, seit QuickDraw veraltet ist (2005).

Zum Verständnis von PICT ist jedoch eins wichtig – Es kann 2 unterschiedliche Hauptinformationen speichern (d.h. “einschließen”):

• Die eigentlichen Angaben der Zeichnung (entweder Bitmap oder vektoriell)
• Oder ein aktuelleres Format (z.B. JPEG), das über QuickTime in einem PICT gespeichert ist. In der Regel hat der Entwickler den Befehl _o_QT COMPRESS PICTURE mit der Konstante QT Photo compressor aufgerufen.

Entwickler sollten beim Migrieren von Versionen vor v11 auf jedes Datenfeld vom Typ Bild die Funktion CONVERT PICTURE anwenden. Beim Migrieren von Daten neuerer Versionen empfehlen wir, den Befehl GET PICTURE FORMATS einzusetzen, um die Bilder in Ihrer Datendatei zu finden, die konvertiert werden müssen.

Codecs für Bilder in einem Format, das QuickTime erfordert, sind überholt.

Die Verwendung von QuickTime ist seit 4D v14 standardmäßig deaktiviert. Als Umstellungshilfe können Sie es bei Bedarf über die neue Option QuickTime Support in den Befehlen SET DATABASE PARAMETER, Get database parameter aktivieren - nach Konvertieren bitte umgehend wieder deaktivieren!

Seit mehreren Jahren hat sich die Bildverwaltung unter der Windows Version von QuickTime nicht weiter entwickelt (nur der Video Bereich entwickelt sich weiter). Wir planen, die Unterstützung dieser spezifischen APIs im nächsten Release zu entfernen.

4D für Windows unterstützt alle gängigen Formate nativ (JPEG, PNG, GIF, TIFF, etc.), dazu gehört auch WIC (Windows Imaging Component). Sollten Ihre Daten unter Windows noch Bilder in einem Format enthalten, das nur von QuickTime erkannt wird, können Sie diese über den Befehl CONVERT PICTURE konvertieren.

Zur Erinnerung: Die 64-bit Version von 4D Server für Windows unterstützt seit 4D v12 keine QuickTime Formate.

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

Altura Mac2Win wurde zur Portierung von 4D auf Windows verwendet. Es besteht aus mehreren APIs, um auf Mac OS geschriebenen Code (vor OS X) auf Windows zu portieren. Es handelt sich um Übersetzungs APIs für das Dateisystem, QuickDraw, Ressourcen, PICT, etc. Das war seinerzeit sehr hilfreich und ermöglichte z.B. Entwicklern, ihre auf Mac erstellten Plug-Ins ohne große Mühe auf Windows zu portieren. Es ist heutzutage veraltet, da es überholte Mac OS APIs emuliert und keine modernen nativen Windows APIs verwendet. Deshalb wurde Mac2Win so weit wie möglich aus dem 4D Code entfernt.

4D ist bis heute noch z.T. von Altura abhängig, hauptsächlich 32-bit Versionen, um die Kompatibilität alter Datenbanken zu gewährleisten, die z.B. noch Ressourcen, PICT und bestimmte Benutzerereignisse oder Plug-Ins von Drittherstellern verwenden, die mit Altura erstellt wurden.

Hinweis: Altura Mac 2Win wurde mit 4D v16 R2 aus den 64-bit Version von 4D Developer Edition und 4D Volume Desktop komplett entfernt. Es wird auch bald aus der 64-bit Version von 4D Server entfernt.

Wir raten Entwicklern, Ressourcen aus der .RSR Datei als getrennte Dateien in den Ordner “Resources” zu setzen und Bilder im PICT-Format mit dem Befehl CONVERT PICTURE in ein anderes Format zu konvertieren, damit sie bereit sind, wenn 4D Altura vollständig entfernt hat. Dieser bedeutsame Schritt betrifft aber in erster Linie Entwickler von Plug-Ins. Sie sollten Altura sobald wie möglich nicht mehr verwenden, d.h. sie müssen einige Teile ihres Quellcode in Windows umschreiben. Darauf weisen wir schon seit mehreren Jahren hin.

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 für Mac OS, wie z.B. Geneva, Chicago werden nicht mehr unterstützt. Sie können auch nicht mehr ID Nummern für Schriften verwenden.
Zur Wahrung der Kompatibilität sind die Funktionen _o_Font number und _o_Font name in 4D v15 und höher noch verfügbar, werden 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)

Die Unterstützung des ASCII Modus, auch Nicht-Unicode Modus genannt, führt bei Bearbeitung von Text zu schlechter Performance, da dieser jedes Mal in und aus Mac-Roman konvertiert werden muss. Der ASCII Modus wird in kommenden Hauptversionen entfernt.

Bitte beachten Sie, dass die Unterstützung des ASCII Modus für kompilierte Strukturen auf 4D Server 64-bit für Windows bereits entfernt wurde.
4D Entwickler sollten in konvertierten Strukturen den Unicode Modus aktivieren. Weitere Hinweise dazu finden sie im PDF Dokument 4D v14 Konvertierung.

Hinweis für 64-bit Versionen: Der ASCII Modus wird in 64-bit Versionen von 4D und 4D Server nicht unterstützt.

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.

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.

Im Zuge der Weiterentwicklung der Versionen wurden die nützlichsten 4D Pack Routinen nach und nach in 4D selbst übernommen und die überholt gewordenen Routinen entfernt. Ab 4D v16 R2 wird das Plug-In 4D Pack nicht mehr mitgeliefert. Die nachfolgende Tabelle zeigt, wie Sie überholte Routinen von 4D Pack ersetzen können.

Das Plug-In OLE_Tools (nur Windows) ist jetzt in 32-bit Versionen von 4D veraltet und wird in 64-bit Versionen von 4D nicht mehr unterstützt. Funktionalitäten dieses bisherigen Plug-In lassen sich je nach Kontext ersetzen durch Web Areas, den Befehl LAUNCH EXTERNAL PROCESS oder PHP.

Für mehr Klarheit in der 4D Programmiersprache haben ab 4D v15 alle überholten Befehle die Vorsilbe "_o_" erhalten, sofern das noch nicht der Fall war. Sie sind in 4D Listen (Code-Editor, type-ahead-Feature, etc.) nicht mehr verfügbar.
Sie werden nicht aus vorhandenem Code entfernt und funktionieren weiterhin, solange sie noch unterstützt werden. Es ist weiterhin möglich - wird aber nicht empfohlen, überholte Befehle in eine Methode einzufügen. Wenn Sie den Namen mit der Vorsilbe _o_ eingeben, wird der Befehl korrekt interpretiert.