Fonctionnalités obsolètes ou supprimées

Depuis plus de 30 ans, notre objectif principal consiste à améliorer notre produit (à l'aide de nouveaux concepts et technologies) tout en assurant la compatibilité des applications 4D. Les nouveaux utilisateurs de 4D le savent, nous nous sommes toujours efforcés d'assurer la compatibilité, permettant à des applications 4D du monde entier créées il y a plusieurs années, avec d'anciennes versions de 4D et d'anciens OS, de rester toujours fonctionnelles dans les dernières versions du produit.

Malheureusement, il est parfois difficile de combiner anciennes technologies et technologies nouvelles :

• 4D doit introduire de nouvelles technologies, de nouveaux IPA et paradigmes pour les développeurs
• Les OS changent continuellement et voient leurs propres anciens IPA devenir parfois obsolètes

C'est pourquoi il arrive que 4D définisse comme obsolètes certaines commandes et fonctionnalités, c'est-à-dire qu'elles sont retirées du langage dans une version majeure future.

Ainsi, en notifiant les développeurs des obsolescences et des remplacements utilisés, il leur est plus facile d'accompagner les changements dans leur code : ces modifications ne se font ni dans l'urgence ni la pression, afin que les développeurs prennent le temps de s'adapter.

Explications sur les valeurs de la colonne "Statut" :

• Supprimé : N'est plus disponible dans la version courante (ou la version indiquée).
• Obsolète : Ne doit plus être utlisé et sera supprimé dans une future version majeure.
• OS : Dépend de technologies rendues officiellement obsolètes par un OS (par exemple le format PICT). Ce statut est identique au statut Obsolète, mais un OS peut en supprimer la prise en charge avant que nous le fassions.

Chaque commande obsolète est préfixée par "_o_" et ne figure plus dans la liste 4D (éditeur de code, fonctionnalité d'auto-complétion, etc.). Les commandes obsolètes (ou dépréciées) ne seront pas supprimées du code existant et continueront de fonctionner normalement, tant qu'elles sont prises en charge. Il est possible (mais non recommandé) d'ajouter une commande obsolète dans une méthode en saisissant simplement son nom préfixé de "_o_" ; elle sera interprétée correctement. 

Une liste alphabétique de ces commandes peut être consultée dans l'annexe Commandes obsolètes de 4D - Langage.

Les commandes suivantes, antérieurement obsolètes, ont été supprimées de 4D et ne doivent pas être utilisées dans votre code. Si elles sont appelées, elles génèreront une erreur (Erreur 33 - Méthode ou fonction non implémentée). 

Attention : Les appels de commandes supprimées ne peuvent pas être détectés par le vérificateur de syntaxe ou le compilateur. Il vous appartient de contrôler le code afin de vous assurer qu'il ne contient pas d'appel à des commandes supprimées. 

L'architecture "projet" représente une évolution majeure des bases de données 4D. Comme les projets intègrent les normes d'interface les plus récentes et les technologies les plus modernes, ils ne prennent pas en charge certaines anciennes fonctionnalités, listées ci-dessous. Ces fonctionnalités sont désormais obsolètes et  ne doivent plus être utilisées dans vos bases de données pour une meilleure conformité avec l'architecture projet de 4D. 

Pour plus d'informations sur l'architecture projet de 4D, veuillez consulter la documentation des projets 4D sur developer.4d.com. 4D fournit un outil permettant d'exporter une base .4db (binaire) en base projet. Lors de l'exportation, les fonctionnalités obsolètes sont automatiquement converties, supprimées ou génèrent des erreurs (voir Conversion des bases en projets).

Les propriétés et objets de formulaire suivants ne sont pas compatibles avec les exigences des interfaces modernes et sont désormais obsolètes. Ils ne sont pas pris en charge dans les Formulaires dynamiques, et pourront être signalés dans le fichier d'historique de conversion en projet (cf. commentaires).  

Les options de structure de la base de données 4D suivantes sont obsolètes et seront modifiées ou généreront des erreurs dans le fichier d'historique de conversion du projet (voir commentaires).  

Les éditeurs ou fonctionnalités suivants de la Boîte à outils sont obsolètes et ne sont pas pris en charge dans les projets.

Les modes de compatibilité permettant de conserver des fonctionnements obsolètes ne sont pas pris en charge dans les projets. Lors de l'exportation d'une base existante en projet, tous les paramètres de compatibilité sont réinitialisés comme pour la création d'une nouvelle base de données. Si votre base utilise encore des modes de compatibilité, vous devez envisager une mise à niveau. 

Nous recommandons fortement la lecture de cette série de billets de blog expliquant comment se passer des modes de compatibilité. 

A compter de 4D v17 R5, 4D et 4D Server ne sont plus proposés en version 32 bits. Seules les versions 64 bits sont désormais disponibles, permettant aux applications 4D de tirer le meilleur parti de cette puissante architecture.

Bien que les versions 64 bits incluents la majorité des fonctionnalités historiques de 4D, elles favorisent les dernières technologies et ne prennent pas en charge celles qui ont été déclarées obsolètes dans les versions précédentes. La mise à niveau des bases développées en versions 32 bits pourrait nécessiter quelques adaptations :

• Pour consulter une liste des anciennes fonctionnalités qui ne sont plus prises en charge dans 4D v18, veuillez vous reporter à la page Tableau récapitulatif de ce manuel.
• Pour adapter vos bases de données, veuillez consulter la page "Passage de 32 bits à 64 bits" du manuel Conversion en 4D v17

Le langage XSLT n'est plus disponible dans 4D.  L'appel d'une commande XSLT génèrera une erreur 33 "".

Afin de ne pas pénaliser nos clients qui utilisent encore le XSLT dans 4D, nous avons choisi de nous appuyer sur la librairie XSL de PHP, qui fournit une API complète vous permettant d'effectuer toutes les actions nécessaires pour vos transformations XSL. Cette librairie est un outil efficace qui pourra aisément remplacer les commandes supprimées _o_XSLT APPLIQUER TRANSFORMATION,  _o_XSLT FIXER ARAMETRE et  _o_XSLT LIRE ERREUR. 4D a conçu un document spécifique pour vous aider à utiliser la librairie PHP XSL en remplacement des commandes XSLT de 4D : Télécharger le document "La transformation XSLT avec PHP" (PDF).

Nous vous suggérons également d'étudier l'utilisation des balises 4D lorsque l'objectif est de générer dynamiquement des pages HTML, puisque dans la plupart des cas il est pratique de traiter le code HTML comme du texte non formaté (voir aussi la commande PROCESS 4D TAGS).

A compter de v17 R5, la prise en charge de QuickTime (via les paramètres de la base) n'est plus assurée. Les codecs d'image liés à QuickTime ne sont plus pris en charge par Windows et macOS.

A partir de 4D v18, le type de champ Float n'est plus pris en charge par la base 4D. Ce type de champ était utilisé uniquement par le moteur SQL de 4D. Si votre base utilisait le type de champ Float, ce dernier est automatiquement converti en un type Réel lorsque la base est ouverte dans une version v18 ou supérieure. Les données existantes ne sont pas converties, sauf si vous les compressez ou si vous re-sauvegardez vos enregistrements.

A compter de 4D v17 R5 et des versions plus récentes, le mode ASCII (aussi appelé "Mode non-Unicode") n'est plus pris en charge. Lorsque vous ouvrez une base de données convertie qui n'était pas définie en Unicode, 4D affiche la boite de dialogue d'alerte suivante : 

Cette alerte sera affichée à chaque ouverture de la base tant que le mode Unicode ne sera pas coché dans la page "Compatibilité" des propriétés de la base. Vous devez - pour les structures converties - activer le mode Unicode. Le document PDF Convertir vos bases en 4D v14 donne des conseils sur ce sujet.

A compter de 4D v17 R5, le format PICT (rendu obsolète par Apple depuis 2005) n'est plus pris en charge. Cela signifie que les images au format PICT ne peuvent  en aucun cas être rendues, elles doivent être converties. Utilisez la commande GET PICTURE FORMATS pour détecter et filtrer les images au format PICT contenues dans votre fichier de données.

Le mode de déploiement des applications 4D monopostes fusionnées sur la plateforme mac à l'aide de la clé DatabaseOutsidePackage dans info.plist n'est plus pris en charge. A compter de 4D v17 R5, la clé DatabaseOutsidePackage est ignorée.

A partir de 4D v17 R4, 4D ne prend plus en charge les interfaces droite à gauche sur Windows. Les options correspondantes ne sont plus disponibles dans les paramètres de la base ou les propriétés du formulaire. Dans les bases converties, les paramètres droite à gauche seront ignorés lors de l'exécution.

A partir de 4D v17 R4, les formulaires utilisateurs sont obsolètes. Pour proposer des interfaces utilisateurs personnalisables, il est désormais recommandé d'utiliser des formulaires dynamiques (voir Formulaires dynamiques dans 4D - Mode Développement). Toutes les commandes du thème "Formulaires utilisateurs" sont obsolètes.

Les formulaires utilisateurs sont encore pris en charge pour des raisons de compatibilité, mais ils ne doivent plus être utilisés. Ils seront retirés des futures versions.

La fonctionnalité 4D Mobile est obsolète à compter de 4D v18 et ne doit plus être utilisée. L'accès aux données via les requêtes REST est maintenant pris en charge par la technologie ORDA et le serveur REST.

Dans les versions précédentes de 4D, le serveur Web recopiait automatiquement la valeur des variables envoyées via un formulaire Web ou une URL dans des variables 4D lorsqu'elles avaient le même nom.

Pour des raisons d'optimisation et de contrôle, ce principe n'est plus maintenu à compter de 4Dv14 : la valeur des variables Web n'est plus automatiquement affectée aux variables 4D. La récupération des variables envoyées via un POST ou un GET doit s'effectuer exclusivement à l'aide de la commande WEB GET VARIABLES. Les fichiers postés devront, eux, être récupérés à l'aide des commandes WEB GET BODY PART et WEB Get body part count.

Note : L'affectation dynamique est également désactivée par défaut dans les bases 4D créées à compter de la version 13.4.

Par compatibilité, ce mécanisme est toutefois maintenu par défaut dans les bases de données créées avec une version de 4D antérieure à la 13.4. Dans ce cas, l'option de compatibilité Affectation automatique de variables sur la page Compatibilité des Propriétés de la Base, permet de le désactiver.

Ce mécanisme étant obsolète, il est fortement recommandé de désélectionner cette option dans vos bases converties (et d'adapter votre code si nécessaire) afin de faciliter leurs évolutions futures.

Depuis plusieurs versions, 4D déconseille fortement aux développeurs d'utiliser des sous-tables, et depuis 4D v11, il n'est plus possible de créer un champ de type sous-table. Les sous-enregistrements ont de nombreuses limitations. Par exemple, ils sont toujours chargés en mémoire et ils ne sont pas gérés par la commande SEND RECORD ou DUPLICATE RECORD.

Nous n'envisageons pas de supprimer définitivement les sous-tables dans un futur proche, mais il est vraiment temps pour les développeurs de convertir leurs sous-tables en tables standard avec une relation N<->1, car cette suppression sera effective dans une future version majeure de 4D. Les développeurs qui utilisaient les sous-tables pour des raisons de performances (comme dans certaines situations spécifiques où le chargement des enregistrements liés était lent) peuvent être rassurés : depuis 4D v12 notamment, l'utilisation des relations classiques N<->1 est très rapide.

Fondamentalement, il y a deux façons principales de supprimer des sous-tables (note : les explications suivantes sont juste un rapide aperçu ; consultez la documentation ou les notes techniques pour plus d'informations) :

• Avant la conversion d'une structure antérieure à 4D v11 : en 4D 2004, créez les Tables N appropriées et le champ ID dans la Table 1 (s'il n'existe pas déjà). Puis changez le code partout où c'est nécessaire (voir-ci-dessous).
• Après la conversion : dans cette situation, 4D a remplacé automatiquement chaque sous-table par une Table N en utilisant une relation spéciale. Ceci permet au langage de fonctionner avec les sous-sélections et les sous-enregistrements. Le développeur 4D doit supprimer cette relation spéciale, la remplacer par une relation standard et changer le code partout où c'est nécessaire (voir ci-dessous).

"Changer le code partout où c'est nécessaire" signifie essentiellement :

• Créer de nouveaux formulaires, mettre à jour les formulaires inclus
• Dans les méthodes (projet, formulaire, objet, etc.) :
  
  • remplacer toutes les commandes du thème "Sous-enregistrements" par les commandes correspondantes sur les sélections ou les enregistrements (par exemple, remplacer la commande _o_CREATE SUBRECORD par la commande CREATE RECORD, en renseignant les champs ID)
  • charger explicitement les enregistrements N lorsque c'est nécessaire.

Note : Depuis 4D v14 R3, vous pouvez affecter la valeur du champ spécial "id_added_by_converter" automatiquement ajouté par 4D lors de la conversion d'une base de données depuis une version antérieure à la v11. Jusqu'alors, cette valeur pouvait uniquement être affectée par 4D, ce qui obligeait les développeurs à utiliser des commandes obsolètes comme _o_CREATE SUBRECORD pour pouvoir ajouter des enregistrements dans les sous-tables converties. Avec cette nouvelle possibilité, vous pouvez convertir vos anciennes bases comportant des sous-tables d'une manière progressive : vous pouvez conserver le lien spécial "Lien sous-table", tout en ajoutant ou en modifiant des enregistrements liés comme s'ils étaient standard. Une fois que toutes vos méthodes auront été mises à jour, vous pourrez remplacer le lien spécial par un lien normal sans changer votre code.  

Les polices QuickDraw (par exemple Geneva, Chicago) sont désormais obsolètes et la sélection des polices de caractères via un numéro d'ID QuickDraw ne doit plus être utilisée. Les commandes et _o_Font name sont maintenues dans 4D v15 et suivantes par compatibilité uniquement et seront supprimées dans les versions suivantes. La commande OBJECT SET FONT accepte désormais uniquement un nom de police.

Il  existe deux types de plug-ins : ceux utilisant la nouvelle API pour plug-ins, et ceux qui utilisent encore l'ancienne (avec QuickDraw).

Pour les plug-ins utilisant l'ancienne ToolBox (avec QuickDraw) : pour maintenir la compatibilité, l'affichage/le rendu n'est plus fait directement sur un port QuickDraw mais par l'intermédiaire d'une zone hors-écran GWorld QuickDraw dédiée au plug-in.

En conséquence, vous devrez respecter certaines règles, comme celle, par exemple, interdisant aux plug-ins de modifier le port courant fixé par le conteneur ('form object').

Pour les plug-ins utilisant la nouvelle ToolBox : seule la nouvelle ToolBox est utilisée, et pas QuickDraw (voir https://github.com/4D/4D-Plugin-SDK).

A compter de 4D v16 R6, les APIs de gestion des fichiers et des dossiers basées sur Mac OS 9 sont obsolètes dans 4D. Ces APIs sont déclarées obsolètes par Apple depuis plusieurs années. 

Les commandes 4D s'appuyant sur ces anciennes APIs ont été renommées : _o_Document type, _o_Document creator, _o_SET DOCUMENT TYPE, _o_SET DOCUMENT CREATOR et _o_MAP FILE TYPES. Ces commandes sont maintenues par compatibilité, mais sont obsolètes et ne doivent plus être utilisées. 

4D inclut deux nouvelles commandes de gestion des chemins d'accès et des extensions de fichiers : Path to object et Object to path.

L'architecture interne des actions standard a été entièrement revue dans 4D v16 R3. Ces actions sont désormais basées sur des chaînes de caractères et prennent en charge des paramètres (pour plus d'informations, veuillez vous reporter à la section Actions standard).

Dans les applications converties, les actions standard sont redirigées de façon transparente vers la nouvelle architecture. Cependant, dans le langage de 4D, les actions standard étaient auparavant basées sur des valeurs numériques (codes). Ce fonctionnement est désormais obsolète et ne doit plus être utilisé :

• Les actions standard texte utilisant des codes du thème de constantes Action standard (précédemment nommé "Valeurs Texte pour Action standard associée") sont préfixées "_o_" et ne doivent plus être utilisées.
• L'ensemble du thème de constantes Valeurs pour Actions standard associée est déclaré obsolète.
• La commande _o_OBJECT Get action (qui retourne un code) est obsolète et a été remplacée par la commande mise à jour OBJECT Get action (qui retourne un nom d'action).

Il s'agit d'une autre ancienne technologie Mac OS, obsolète depuis Mac OS X 10.4 (Tiger, 2005). Les ressources sont utilisées pour stockées des données structurées comme du texte ou des chaînes (pour la localisation), des icônes, etc. En fait, il faut dire que ce ne sont pas les ressources en elles-mêmes qui sont obsolètes, mais leur support sur disque, connues en tant que ResourceFork. La ResourceFork est une partie d'un fichier système Mac OS, et depuis la sortie de Mac OS X, Apple cherche à supprimer ce support car il n'est pas compatible avec les autres systèmes (Unix, Windows) et il est source de beaucoup de problèmes lorsque des fichiers sont transférés par réseau.

Sous Windows, ce mécanisme est émulé et les ressources Mac résident dans le fichier .RSR.

Mais même s'il existe encore des APIs pour gérer les ressources (et Mac OS gère de façon transparente les ressources stockées dans la DataFork), il n'est plus recommandé d'utiliser cet ancien mécanisme pour plusieurs raisons :

• les textes et les chaînes sont en Mac-Roman. Vous pouvez pas stocker de l'Unicode dans des ressources de type TEXT ou STR#.
• les ressources PICT stockent des PICTs : format non moderne, obsolète, qui ne gère pas la transparence, etc. (voir le point "Images au format PICT" ci-dessus).
• le nombre de ressources et leur taille sont limités (environ 2 700 ressources ou 16 Mo). 

Nous avons supprimé le support des commandes qui permettent d'écrire/créer des ressources.

La grande majorité des applications 4D utilisant des ressources utilisent en fait des ressources de type "Listes de chaînes", des STR#. 4D fournit les outils pour déplacer aisément les STR# vers du XLIFF :

• Le composant 4D Pop peut créer automatiquement les fichiers XLIFF par la lecture et le transfert des STR#.
• Toutes les commandes et expressions qui font référence à des STR# fonctionnent sans modifications avec le XLIFF. Par exemple, si le libellé d'un bouton ou d'un menu était ":15000,3" (ce qui signifie "récupérer le 3e item de la STR# 15000), 4D chargera le XLIFF approprié (s'il existe).

Pour les autres types de ressources :

• Placez les ressources dans des fichiers séparés dans le dossier "Resources" à côté de la structure (créez des sous-dossiers si nécessaire) :
  
  • Sauvegardez les ressources 'TEXT' en XLIFF ou en fichiers .txt.
  • Sauvegardez les ressources 'PICT' en tant que fichiers jpg/.png/etc. séparés.
  • Sauvegardez les ressources 'PICT' + MASK’ en tant que fichiers png.
  • Stockez vos ressources privées de la façon la plus appropriée (par exemple, transférez des données binaires dans un document sur disque).
• Utilisez le dossier "Resources" pour stocker vos ressources. Pour récupérer dynamiquement le chemin d'accès à vos ressources, utilisez Dossier 4D (Dossier Resources courant).

La modification des priorités CPU est un paramétrage obsolète. La gestion mémoire des applications 4D a été optimisée au fil des versions et il est désormais inutile voire contre-performant de modifier les paramètres par défaut. Par conséquent :

• la zone "Priorité CPU" (page "Général" des Propriétés de la base) est désormais affichée uniquement dans les bases converties si une valeur personnalisée avait été précédemment définie. Il est recommandé dans ce cas de cliquer sur le bouton Réglages d'usine afin de réinitialiser les paramètres et de les supprimer de la boîte de dialogue. 
• à compter de 4D v16 R2, les sélecteurs obsolètes de SET DATABASE PARAMETER ont été renommés (_o_4D Remote mode scheduler, _o_4D Local mode scheduler et _o_4D Server scheduler) et ne doivent plus être utilisés.