Fonctionnalités obsolètes ou supprimées dans la gamme v16

Les versions 64 bits de 4D privilégient les technologies les plus récentes et ne prennent pas en charge celles qui ont été déclarées obsolètes dans les versions précédentes du programme. Pour une liste complète des fonctions non prises en charge dans la gamme 64 bits de 4D, veuillez vous reporter à la section Spécificités des versions 64 bits dans le manuel Mode Développement.

Le langage XSLT transforme des données XML vers divers formats (XML, HTML ou tout autre type). Les principaux navigateurs Web tout comme le logiciel 4D ont implémenté la spécification XSLT 1.0.

Aujourd'hui, le XSLT est en net déclin car les développeurs considèrent qu'il est difficile à utiliser et à déboguer. Au vu de cette tendance, ainsi que du retour de nos développeurs, nous avons décidé que la fonction de transformation XSL ne sera pas développée pour les versions 64 bits de 4D. 

Note : Pour visualiser les tendances de recherche sur XSLT dans Google: http://www.google.com/trends/explore#q=xslt      

Cependant, 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 _o_XSLT APPLY TRANSFORMATION, _o_XSLT SET PARAMETER et _o_XSLT GET ERROR après leur retrait. 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).

Par compatibilité, les transformations XSL sont toujours prises en charge dans 4D, mais leur usage est désormais déconseillé. Le support des traitements XSLT seront supprimés des versions futures de 4D.

Note versions 64 bits : Le XSLT n'est pas disponible dans les versions 64 bits de 4D (OS X et Windows) ainsi que dans 4D Server 64 bits pour OS X. Par conséquent, l'appel d'une des commandes XSLT depuis ces applications générera l'erreur 33, "Méthode ou fonction non implémentée".   

Le format PICT ne sera plus pris en charge dans les prochaines versions majeures de 4D et vous ne devez plus l'utiliser. La commande GET PICTURE FORMATS vous aide à détecter et filtrer les images utilisant le format PICT dans vos données (la fonction _o_AP Is Picture Deprecated de 4D Pack est désormais obsolète).

Note : Le format "PICT" a été déclaré obsolète par Apple depuis plusieurs versions de Mac OS (voir la description du format PICT sur Wikipedia).

Le format "PICT" est un format Mac très ancien. Avant la version 11, 4D stockait toutes les images dans ce format, même sous Windows. Le format PICT a été déprécié depuis que QuickDraw a été déclaré obsolète, en 2005.

Il y a un point important à comprendre à propos des PICT : elles peuvent stocker (lire "encapsuler") deux sortes d'informations :

• le dessin des primitives elles-mêmes (bitmap ou vectorielles), ou ;
• un format plus moderne (JPEG par exemple) encapsulé dans le PICT en utilisant QuickTime. Généralement le développeur utilisait la commande _o_QT COMPRESS PICTURE avec la constante QT compresseur photo).

Cela signifie que même lorsque toutes les images stockées dans le fichier de données étaient des PICT, ces images pouvaient, en fait, contenir du JPEG (ou un autre format). Il est important d'arrêter d'utiliser les PICT, non seulement parce que c'est un format obsolète, mais aussi parce que 4D a besoin d'Altura (+ QuickTime si _o_QT COMPRESS PICTURE est utilisé) pour lire les PICT sous Windows. Cela n’est pas toujours efficace, et il est parfois difficile d’installer QuickTime sur des machines Windows.

Lorsque vous convertissez des données de versions antérieures à 4D v11, il faut utiliser la commande CONVERT PICTURE sur chaque champ image de la base de données. Lorsque vous convertissez vos données depuis des versions plus récentes, nous vous recommandons d'utiliser la commande GET PICTURE FORMATS pour trouver les images qui doivent être converties dans les données.

A compter de 4D v16, vous pouvez détecter les images contenant le format PICT dans la structure de votre base à l'aide du CSM (Centre de Sécurité et de Maintenance). Lorsque vous utilisez la fonction Vérifier l'application, le fichier de compte-rendu généré contient des warnings supplémentaires pour signaler les images contenant ou utilisant le format PICT. Ces warnings peuvent concerner les images statiques ainsi que les images stockées dans la bibliothèque d'images ou dans les objets de formulaire.

Note : Il vous appartient de supprimer ou de remplacer manuellement chaque image contenant le format PICT. Utiliser le CSM pour lancer une opération Réparer le fichier de structure n'aura pas d'effet sur ces images "obsolètes", les mêmes warnings seront générés dans son fichier de compte-rendu.

La prise en charge des codecs d'image liés à QuickTime est désormais obsolète.

Par défaut, l'utilisation de QuickTime est désactivé depuis 4D v14. Mais pour des raisons de compatibilité, vous pouvez le réactiver en utilisant la nouvelle option Prise en charge QuickTime avec les commandes SET DATABASE PARAMETER et Get database parameter (hormis dans les versions 64 bits de 4D, où QuickTime n'est pas pris en charge). 

Depuis plusieurs années, la gestion d'images proposée par la version Windows de QuickTime n'évolue plus (seule la partie vidéo a évolué). Nous projetons de supprimer la prise de charge de ces APIs dans une version future.

4D sous Windows supporte nativement tous les principaux formats (JPEG, PNG, GIF, TIFF, etc.) ainsi que WIC (Windows Imaging Component). Si, dans vos données, vous avez des images sauvegardées, sous Windows, dans un format spécifique connu seulement par QuickTime, vous pouvez les convertir (CONVERT PICTURE).

Nous vous rappelons aussi que les formats d'images QuickTime ne sont pas pris en charge dans la version 64-bit de 4D Server sous Windows.

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.

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 _o_Font number 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.

Altura Mac2Win a été utilisée pour le portage de 4D sous Windows. C'est un ensemble d'APIs qui permettent de transporter le code Mac OS (avant OS X) vers Windows en convertissant les APIs : filesystem, QuickDraw, Resources, PICT, etc. C'était très pratique et d'une grande aide (les développeurs de plug-ins Mac, par exemple, pouvaient ainsi transférer leurs plug-ins sous Windows plus facilement), mais ce transfert était basé sur d'anciennes APIS (lisez "obsolètes") et n'utilise pas les APIs Windows modernes natives : 4D doit supprimer au maximum Mac2Win de son code. C'est un travail long et fastidieux, et dans chaque version de 4D, quelques dépendances sont supprimées (et remplacées par des APIs modernes).

À l'heure actuelle, 4D dépend encore partiellement de ces APIs, principalement pour pouvoir gérer la compatibilité des anciennes bases de données : Ressources, PICT, une partie de la gestion des événements utilisateur, la prise en charge des plug-ins tiers utilisant Altura, etc.

En supprimant les ressources dans le fichier .RSR pour les placer dans des fichiers séparés dans le dossier "Resources", et en convertissant les images (CONVERT PICTURE) dans un autre format que le format PICT, les développeurs seront prêts lorsque 4D supprimera Altura. Mais les premiers concernés par cette importante étape sont les développeurs de plug-ins. Ils doivent cesser d'utiliser Altura dès que possible, ce qui signifie qu'ils doivent réécrire certaines parties de leur code source sous Windows (cette information quant au retrait progressif d’Altura a déjà été fournie aux développeurs de plug-ins).

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.  

Le support du mode ASCII (aussi appelé "Mode non-Unicode") entraîne des performances médiocres lors de la manipulation de texte, car il doit être converti vers le (et du) Mac-Roman chaque fois qu'il est utilisé dans une structure convertie. Nous envisageons de supprimer le mode ASCII dans une future version majeure de 4D.

Notez que le support du mode ASCII était déjà supprimé dans les structures compilées tournant sous 4D Server 64 bits sous Windows.

Les développeurs 4D - pour les structures converties - doivent activer le mode Unicode. Voir le document PDF Conversion en 4D v14 qui donne des conseils sur ce sujet.

Note versions 64 bits : Le mode ASCII n'est pas pris en charge dans les versions 64 bits de 4D et 4D Server.

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.
  • Utilisez des icns (sur Mac) à la place des 'ICON' ou des icônes couleur.
  • 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).

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 : http://sources.4d.com/trac/4d_4dpluginapi/wiki/native_drawing).

Au fil des versions, les routines les plus utiles de 4D Pack ont été intégrées à 4D et celles qui sont devenues obsolètes ont été supprimées. 4D Pack v16 contient désormais un nombre réduit de routines et n'évoluera plus. A compter de 4D v16, le plug-in 4D Pack dans son ensemble est obsolète. Il ne sera plus proposé dans les futures versions de 4D. Reportez-vous au tableau ci-dessous pour connaître les solutions de remplacement (si disponibles) pour les routines restantes.

Le plug-in OLE_Tools (disponible sous Windows uniquement) est désormais obsolète dans les versions 32 bits de 4D et n'est pas pris en charge dans les versions 64 bits. Les fonctionnalités de cet ancien plug-in peuvent être remplacées, suivant les cas, par les Zones Web, la commande LAUNCH EXTERNAL PROCESS, ou le PHP.

Pour plus de clarté dans le langage de 4D, à compter de 4D v15, toutes les commandes obsolètes sont systématiquement préfixées "_o_" et ne sont plus proposées dans les listes des éditeurs de 4D (éditeur de code, saisie prédictive...).
Elles ne seront pas supprimées du code existant et continueront de fonctionner normalement tant qu'elles seront prises en charge. Il reste même 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.