Depuis Adélia Studio 11, il est possible de générer les applications Visual Adélia et Adélia Web en Unicode.
Adélia respecte la norme UCS-2 (encodage des caractères de largeur fixe sur deux octets) qui permet de représenter 65535 caractères, que l'on va distinguer du codage standard sur un seul octet (single-byte) qui ne peut en représenter que 255.
L'utilisation d'Unicode apporte de nombreux avantages :
support amélioré des applications multilingues (possibilité de représenter des caractères appartenant à plusieurs alphabets dans une même application),
réduction voire suppression des problèmes de configuration ou de conversion de page de code entre les différents tiers (Middleware client/serveur, base de données),
compatibilité avec les thèmes Windows XP / Vista : vous devez intégrer les lignes suivantes dans le manifeste de votre application.
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' />
</dependentAssembly>
</dependency>
Restrictions d'utilisation
Les versions Unicode et Ansi des applications générées ne peuvent pas communiquer (elle s'exécutent avec des runtimes différents). Il est donc impossible d'appeler un programme Ansi depuis une application Unicode et inversement, la chaîne complète de programmes doit être compilée avec les mêmes paramètres. Cela s'applique aussi aux applications Web. En partie serveur AS/400 uniquement, il est possible d'appeler un programme Ansi depuis une partie serveur compilée en Unicode (APPELER ... *NON_UNICODE).
L'utilisation de EXECUTER_CMD est par contre autorisée de façon croisée.
Les ordres d'accès fichiers natifs (LIRE, LIRE_AVANT, METTRE_A_JOUR, CREER, SUPPRIMER...) sont interdits dans un programme généré en Unicode.
Il est possible d'appeler depuis une application Unicode une fonction de DLL prenant des paramètres en Ansi (utilisation de l'ordre APPELER_DLL *NON_UNICODE). L'inverse est impossible.
Si vous avez développé votre propre DLL d'interface, vous avez 3 possibilités pour l'utiliser :
- l'appeler en mode Ansi (APPELER_DLL *NON_UNICODE) si cela est possible ;
- recompiler une version entièrement Unicode de la DLL (non compatible avec les applications Ansi) ;
- fournir une version contenant les implémentations Ansi et Unicode des fonctions : dans ce cas, il suffit d'ajouter le suffixe "$W" au nom de la fonction pour la version Unicode de la fonction, le chargeur de librairie Unicode essayant d'abord de chercher "NomFonction$W" avant d'essayer "NomFonction".
Dans ce cas, la DLL pourra être employée aussi bien avec des applications Ansi qu'avec des applications Unicode.
Attention : Appeler une fonction de DLL Ansi depuis une application Unicode (sans le flag *NON_UNICODE), ou une fonction Unicode depuis une application Ansi a toutes les chances de générer des dysfonctionnements voire des crashes de l'application.
Notes :
Bien que les clients Java (VISUAL ou WADELIA) soient déjà en Unicode dans les versions précédentes, il y a un sens à générer les applications en mode Unicode : dans la version précédente, les modules serveurs étaient générés en single-byte, et les communications Middleware se faisaient aussi en single-byte (sauf de client Java à serveur Java).
Une application Unicode peut communiquer avec une base de données non-Unicode, mais vous pouvez avoir des problèmes de conversion si vous tentez d'insérer des caractères non supportés par la page de code de la base de données.
Une application non-Unicode peut communiquer avec une base de données Unicode, mais vous pouvez avoir des problèmes de conversion si vous lisez des caractères n'existant pas dans la page de code du système.