Nous avons commencé une série d’articles de blog sur les paramètres de compatibilité et les options secrètes qui peuvent vous aider à améliorer considérablement les performances et le comportement de vos applications. Le premier article portait sur QUERY BY FORMULA.
La deuxième partie de la série sur la compatibilité concerne l’utilisation internationale de vos applications professionnelles. Il peut s’agir de vendre à d’autres pays ou de faire venir des collègues d’autres pays pour travailler pendant un certain temps, mais en utilisant leurs systèmes locaux.
Si vous avez déjà vu ou obtenu des rapports du type « les chiffres sont affichés à l’adresse >>>>>>>>> », cet article de blog est pour vous.
Vous ne savez pas comment vos numéros seront affichés ? Vérifiez les paramètres de votre base de données :
Si l’option ci-dessus est déjà activée ou ne s’affiche pas du tout (applications créées avec 4D v11 ou plus), tout va bien et il n’est pas nécessaire de poursuivre la lecture.
Comment cela doit-il fonctionner ?
Le développeur de 4D conçoit pour une utilisation internationale, tandis que l’utilisateur final peut utiliser tous les paramètres régionaux, même des paramètres mixtes en mode client/serveur.
Exemple : « ###,##0.00 » affiché en Allemagne comme « 1.234,56 », aux USA comme « 1,234.56 », en Suisse comme « 1’234.56 ».
Comment cela fonctionnait auparavant (mode de compatibilité)
Le développeur de 4D avait été conçu pour un paramètre régional donné (généralement le paramètre local) et l’utilisateur final devait avoir exactement les mêmes paramètres.
Exemple : « ###,##0.00 » affiché en Allemagne comme « >>>>>>>> », aux États-Unis comme « 1 234.56 », en Suisse comme « >>>>>>>>> ».
Comment cela fonctionne maintenant (développement international)
Dans les versions récentes de 4D, tout ce qui se trouve dans les méthodes 4D est dans un format international :
- Une valeur numérique constante est définie en utilisant un point comme délimiteur décimal international (par exemple, 5,3).
- Les dates sont définies en utilisant le format international « yyyy-mm-dd » (2018-07-31). Notez le « – » utilisé comme délimiteur et l’ordre de l’année, du mois et du jour.
- Les heures sont définies au format 24 heures.
Dès que la valeur est affichée (ou formatée), les paramètres régionaux actuels sont utilisés.
Par exemple, j’écris ce billet de blog sur un système allemand, donc String(!2018-07-31 !) donne « 31.07.2018 » et String(5.3) donne 5,3. Des résultats différents avec des paramètres régionaux différents – pour la même application.
Cela nécessite un changement de mentalité pour les développeurs de longue date, mais le résultat est que vous obtenez des applications internationales sans effort supplémentaire.
Conseils pour la migration
Pour modifier le comportement des paramètres régionaux, vous devez modifier chaque endroit où les paramètres locaux sont codés en dur. Cela pourrait être une mission presque impossible. C’est pourquoi il existe une option de compatibilité et qu’elle est réglée sur « compatible » par défaut.
Mais il y a beaucoup à gagner, alors voyons à quel point c’est vraiment difficile.
Constantes codées en dur dans les méthodes
Bonne nouvelle ! Il n’y a rien à faire pour vous. Lorsque vous créez une méthode 4D en v2004 et que vous écrivez $i:=5,3 (système allemand) et que vous ouvrez cette méthode dans 4D v16 ou plus récent, vous verrez $i:=5.3.
C’est la même chose pour les dates et les heures. Problème résolu !
Utilisation des formats numériques – filtres.
Bien que 4D autorise le codage en dur des formats (par exemple, « ###.##0,00« ) dans les méthodes ou les formulaires, nous vous le déconseillons depuis plus de 20 ans.
Si vous avez utilisé des filtres partout, il sera extrêmement facile de les modifier. Vous pouvez avoir 5 ou 10 filtres, mais probablement pas plus de 20. Vous devrez donc modifier vos filtres du format local au format international (c’est-à-dire en utilisant des points (« . ») pour les décimales et des virgules (« , ») pour le séparateur de milliers).
Une fois cette opération terminée, activez la case à cocher de la compatibilité et le tour est joué !
Comment trouver les filtres codés en dur dans les méthodes
Cette étape n’est pas aussi facile que celles mentionnées ci-dessus. Bien que vous ayez peut-être utilisé des filtres dans vos applications, vous n’êtes peut-être pas certain d’avoir (occasionnellement) ignoré les filtres et créé un code « rapide et sale » dans certains cas.
Exemple :
$text:= String(5300 ; "### ##0") // to be used in Sweden with a space for thousands
Comment les trouver ?
Comme il n’y a pas tant de formats différents, c’est simple !
##0 ^^^0 0,00 ***0 sont des formats typiques. Seule une partie (aussi unique que possible) du format est nécessaire. Si vous trouvez un de ces fragments de texte dans vos méthodes, il y a de fortes chances qu’ils soient codés en dur. Utilisez l’outil Rechercher en mode conception pour rechercher ces morceaux de code et parcourez les résultats.
Si vous n’en trouvez que quelques-uns, parcourez-les manuellement et remplacez-les par des filtres, tels que :
$text:= String(5300 ; "|mynumberformat") // vertical line before filter name
Si vous en trouvez beaucoup, parcourez-les manuellement et vérifiez que votre condition de recherche était correcte. Affinez-la si nécessaire.
Cela peut demander un peu de travail, mais vous serez en mesure de définir des modèles pour résoudre la plupart des cas. Ces modèles devraient permettre une opération automatique de « recherche et remplacement ».
En fonction de l’effort requis, vous pourriez même écrire une méthode pour parcourir votre code et effectuer des recherches pour vous, en utilisant les méthodes METHOD GET CODE et METHOD SET CODE pour vous rechercher.
Comment trouver tous les filtres codés en dur dans les formulaires ?
4D ne fournit pas d’option de recherche pour les formulaires, vous ne pouvez donc pas vérifier automatiquement les formats codés en dur qu’ils contiennent. Mais comme nous sommes des développeurs, nous pouvons le faire nous-mêmes…
Tout d’abord, nous devons obtenir une liste de tous les formulaires pour toutes les tables et les parcourir en boucle. Ensuite, pour chaque formulaire, nous obtiendrons une liste de tous les objets et nous les parcourrons également. Et enfin, pour chaque objet, nous vérifierons s’il utilise un format numérique et si c’est le cas, nous verrons s’il est codé en dur. Si c’est le cas, nous le signalons.
La bonne nouvelle : ce code fournira une liste similaire à l’option Find en mode conception pour les méthodes. La mauvaise nouvelle : vous devrez ouvrir chaque résultat et attribuer manuellement le format, ce qui pourrait prendre un certain temps.
$report:=""
For ($table;0 ;Get last table number)
ARRAY TEXT ($arr_Names;0)
If ($table=0) // project forms
FORM GET NAMES ($arr_Names)
Else
If (Is table number valid($table))
FORM GET NAMES (Table($table)-> ;$arr_Names)
End if
End if
For ($forms;1 ;Size of array($arr_Names))
If ($table=0)
FORM LOAD ($arr_Names{$forms})
Else
FORM LOAD (Table($table)-> ;$arr_Names{$forms})
End if
FORM GET OBJECTS (arrObjNames;arrObjPtrs;arrPages;Form all pages)
For ($i;1 ;Size of array(arrObjNames))
$type :=OBJECT Get type(* ;arrObjNames{$i})
If (($type=Object type text input) | ($type=Object type listbox column) \
| ($type=Object type listbox footer) | ($type=Object type static text))
$format :=OBJECT Get format(* ;arrObjNames{$i})
If (($format#"") & (($format#"|@")))
If (($format="@,@")|($format="@.@"))
$report:=$report+$arr_Names{$forms}+char(9)+ "nom de l'objet : "+arrObjNames{$i}+char(9)+ "format : "+$format+char(13)
End if
End if
End if
End for
FORM UNLOAD
End for
End for
If ($report= "")
$report :="Tout va bien !"
End if
ALERT ($report)
SET TEXT TO PASTEBOARD ($report)
ordre des opérations
Dans votre application actuelle :
- Vérifiez vos filtres et créez-en de nouveaux (si nécessaire).
- Laissez tous les filtres continuer à utiliser les paramètres régionaux… pas encore de changements !
- Changez toutes les méthodes et tous les formulaires pour utiliser les filtres
- Déployez
En même temps, avec une copie de votre application :
- Soit en interne, soit pour des bêta-testeurs sélectionnés :
- Changez les filtres pour utiliser le format international
- Activez la case à cocher de la compatibilité
- Compiler et déployer pour les testeurs pendant plusieurs semaines
- Une fois que tout est testé et vérifié, déployez pour tous (remplacez l’existant)
Commandes connexes
Même si, dans presque tous les cas, vous souhaitez que les nombres soient formatés en fonction des paramètres régionaux, il existe quelques exceptions. Par exemple, vous pouvez utiliser des règles différentes lorsque vous importez ou exportez des données. Cela dépend de la personne qui utilisera ou qui a fourni les données. Un autre exemple est celui des données au format XML ou JSON, qui utilisent toujours un point (« . ») comme séparateur décimal.
Votre travail consiste uniquement à gérer ces exceptions, et non le comportement normal.
Pour convertir un nombre en chaîne de caractères en utilisant un point comme séparateur décimal, partout dans le monde, indépendamment du paramètre régional de l’utilisateur, utilisez :
String($mynumber; "&xml" )
Remarque: même le format est nommé XML, il peut donc être utilisé dans n’importe quel cas, tant que vous souhaitez utiliser un point comme séparateur décimal.
D’autre part, lorsque vous voulez analyser une chaîne de caractères et que vous savez que la chaîne utilise un point comme séparateur décimal( parce que vous l’avez importée d’un document XML ou JSON), utilisez :
Num($mystring; ".")
Conclusion
Pour les applications plus anciennes et bien établies, un certain travail peut être nécessaire, mais il en résulte des applications que vous pouvez déployer partout avec des formats numériques corrects. Cela soulagera votre support technique et aidera également vos clients. C’est du gagnant-gagnant !