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. 

A partir de 4D v19, le plug-in 4D ODBC Pro n'est plus disponible sur l'ensemble des plateformes. Nous recommandons d'utiliser le pass-through intégré ODBC/SQL (voir SQL LOGIN et Présentation des commandes du thème SQL) ou l'API REST 4D  pour gérer les fonctionnalités de connectivité ODBC/SQL.

À partir de 4D v19, le plug-in 4D for OCI n'est plus disponible sur macOS. Nous recommandons d'utiliser le pass-through intégré ODBC/SQL (voir SQL LOGIN et Présentation des commandes du thème SQL) ou l'API REST 4D  pour gérer les fonctionnalités de connectivité sur cette plateforme.

À partir de 4D v19, le pilote ODBC de 4D  n'est plus disponible sur macOS. Nous recommandons d'utiliser l'API 4D REST pour l'accès aux données externes sur cette plateforme.

L'option de stockage dans un fichier de données externes n'est plus prise en charge pour les champs de type objet (voir Stocké dans l'enregistrement, dans le fichier de données, en dehors du fichier de données). Si cette option a été sélectionnée pour un champ objet, elle est automatiquement convertie en Dans le fichier de données et utilisé pour les nouveaux enregistrements. Les données existantes dans les champs objet sont réécrites de manière transparente au nouvel emplacement lorsque l'enregistrement parent est enregistré. Si vous souhaitez étendre ce mode aux enregistrements existants, vous devez compacter les données avec l'option "Forcer la mise à jour des enregistrements". 

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.

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 LIRE VARIABLES. Les fichiers postés devront, eux, être récupérés à l'aide des commandes WEB LIRE PARTIE CORPS et WEB Lire nombre parties corps.

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 ENVOYER ENREGISTREMENT ou DUPLIQUER ENREGISTREMENT.

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_CRÉER SOUS ENREGISTREMENT par la commande CREER ENREGISTREMENT, 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_CRÉER SOUS ENREGISTREMENT 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.  

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_Type document, _o_Createur document, _o_CHANGER TYPE DOCUMENT, _o_CHANGER CREATEUR DOCUMENT et _o_ASSOCIER TYPES FICHIER. 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 : Chemin vers objet et Objet vers chemin.

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_OBJET Lire action (qui retourne un code) est obsolète et a été remplacée par la commande mise à jour OBJET Lire 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 ne 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).