Le séparateur décimal de NSNumberFormatter n'est plus francisé ?
laudema
Membre
Bonjour,
Je me permets de vous soumettre ce problème dont je m'étonne de ne pas avoir trouvé trace ici ou ailleurs via Google (mais j'aurais sûrement mal cherché).
Depuis des lustres j'utilise des NSNumberFormatter dans mon application. Basiques, ajoutés dans IB sur les champs texte ou dans les cellules de mes NSTableView qui affichent des nombres. Et jusque Mountain Lion le séparateur décimal reprenait celui indiqué dans les Préférences Système/Langue et région/Avancées/ Onglet "Général" comme sur cette image
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Effectivement, c'est louche. ???
Ton application plante quand j'essaie d'ajouter 4
Est-ce que ton application a une localisation FR ? (une idée comme ça)
Sinon bah bug report
J'ai été pour la première fois sous xcode 5 pour voir ce projet. La première question qui me vient est la même que celle posée par yoann: que ce passe t-il si tu ajoutes la localisation Française?
J'ai essayé de l'ajouter, mais je n'y suis pas arrivé (il me faut lire la doc, je ne connais rien d'Xcode5!).
Non, et encore moins la démo
Et je pense que je ne serais pas le seul déçu si Apple décidait qu'il faut tout mettre dans le bon dossier .lproj pour avoir ses préférences système prises en compte !
Donc j'ai envoyé un rapport à bugreport, bonne idée, et créé une petite fille de NSNumberFormatter avec un awakeFromNib modifié pour que le bon séparateur soit désigné à la naissance
et ça ira très bien comme ça en attendant.
Merci pour avoir confirmé.
à‰tant un peu comme toi j'ai préféré créer MyFNumberFormatter et plonger dans mes .xib là où le besoin se fait sentir.
ça m'a obligé à faire un click supplémentaire pour passer de la scroll view à la table view. Je viens de vérifier avec Xcode 4 il n'y a pas cette NSClipView qui vient s'intercaler.
Xcode 5, si ce n'était pour la nouvelle version, enfin corrigée, de IKScannerView je pense que je chercherais à revenir au 4. Je trouve sa doc moins agréable, moins pratique et au final moins rapide à l'usage, entre autres. Il a surement ses avantages, mais plus probablement pour de nouvelles applications "from scratch".
Cela se discute. Tu trouves pratique d'avoir une localisation Anglaise dans laquelle s'introduisent les ponctuations et séparateurs décimaux Français. C'est peut être pratique, mais franchement pas logique!! Entre le Français et l'Anglais l'impact est faible et compréhensible (pour nous). Mais qu'en est-il entre l'Anglais et l'Arabe, le Fidgien ou le Népalais? Je suppose que certains cas doivent être catastrophiques.
Il y a un truc étrange. Chez moi ça marche correctement sur une démo que je viens de faire. Je regarde plus en détail ton samplecode.
Tiens, voilà la bonne manière de faire. Il ne faut pas utiliser les number formater directement dans la TableView. Il faut passer par un NSValueTransformer.
Tu veux dire : "il ne faut plus utiliser les number formatter" ?
Parce que ça ne concerne pas que les table views, c'est aussi vrai des champs texte.
En plus ces objets formatters sont toujours disponibles dans la librairie. Et ceux des dates fonctionnent correctement.
Et je n'ai rien trouvé dans la documentation là dessus ...
Non c'est juste la table view (ou le NSArrayController) qui fou le bordel. Regarde mon exemple et tu verra que les TextField avec NSNumberFormatter fonctionnent très bien tant qu'ils sont connecté à un NSNumber directement.
Le problème est quand ça sort d'un NSArrayController / c'est lié indirectement à une NSTableView où là , au lieu de passer le NSNumber à ton format, il passe le stringValue. C'est en tout cas l'impression que j'ai.
Bonjour Yoann et merci du temps que tu m'as consacré.
Je n'ai pas vu dans tes messages de lien avec ton exemple.
Mais j'ai rajouté un champ avec formatter tout prêt depuis la bibliothèque IB, sans le relier au NSArrayController, rien d'autre qu'une IBAction qui prend la "floatValue" du textField en fait un NSNumber envoyé à la méthode stringFromNumber d'un [NSNumberFormatter new] dont le style est défini comme NSNumberFormatterDecimalStyle.
Avec ce champ isolé toujours pas moyen d'entrer un décimal via le clavier numérique français, il faut un '.' et pas une ',' sinon j'ai un Beep et l'action ne se déclenche pas. Mais si j'entre un décimal valide, avec un point, l'action se déclenche et l'alerte me montre bien le décimal, avec une virgule...
Non, ce que je trouve pratique c'est de pouvoir commencer à travailler sur les xib des templates offerts par Xcode sans me soucier de la localisation de mon application quand je sais que mon application n'aura jamais besoin d'être localisée. Je ne vois pas pourquoi je devrais me rajouter le travail de gérer un dossier fr.lproj en plus du en.lproj, juste pour avoir mes préférences système prises en compte.
En plus, oui, ça permet, jusque maintenant, d'utiliser des applications de langue anglaise qui n'ont pas été francisées sans se départir de ses habitudes de saisie. Donc ça me semble pratique.
Je ne comprend pas. Ton dernier sample est grosso modo le même que le premier que j'ai publié.
Est-ce que le premier publié marche chez toi ?
Repart de 0 complet. Projet vierge avec juste un champ et l'alert view. Et tu nous écris ici exactement ce que tu fait en mode journal.
Mode journal ?
Je crée une appli Cocoa dans Xcode 5 avec les réglages de base, ni Document-Based, ni Core Data.
Dans la fenêtre de MainMenu.xib je glisse un TextField with Number Formatter tout prêt depuis la bibliothèque d'objets, déplie les triangles du textField pour arriver au Formatter et dans les propriétés de l'objet je vérifie qu'il a un comportement 10.4+ par défaut et qu'il est de style Decimal avec la case Localize bien cochée. Pour regarder, dans la case Sample j'entre 1,234 et quand je valide ça ça me donne 1 autant dans la case unformatted que formatted, alors que si j'entre 1.234 alors la saisie et validée mais dans les 2 cases je lis 1,234, y compris dans la "unformatted" où j'avais entré 1.234 !
Je crée une IBAction d'un clic droit sur le champ texte glissé jusque sur AppDelegate.h et je remplis la méthode dans le fichier d'implémentation.
.
Build puis Run l'application et
- j'entre 1,234 et je lis "1234.000 doit être égal à 1 234"
- j'entre 1.234 et je lis "1.234 doit être égal à 1,234"
- je veux 1,234 et lire "1.234 doit être égal à 1,234"//Le 1er étant le formatage normal de %f.
Bon, ce qui est bien c'est que tu as contaminé ma machine. Je reproduit le problème ici alors que précédemment ça marchait sur mes sample. J'essaye de comprendre.
C'est énorme ! J'ai deux projet avec les mêmes réglages, créés sur la même machine et qui ne sortent pas le même résultat !
Au passage je me rend compte que les PJ de mes précédents messages n'étaient jamais parties !!! Il faut cliquer sur joindre avant de poster...
Elles sont ici.
Je viens de voir quelque chose d'intéressant en faisant un diff sur les xib.
Les xib contiennent les réglages complets des formater en mode custom. Les options 10.4+ Default ne semble que régler ces valeurs par défaut sur du custom.
Et c'est là où ça commence à être n'importe quoi. La fonction localize ne fait rien du tout. Si je passe mon système avec un séparateur de décimal en point pour les décimal au lieu de la virgule, le comportement de mon application ne change pas.
Il y a clairement un bug sur le système de gestion des décimales.
Il va falloir faire un bug report très précis en partant de la langue anglaise pour avoir une chance que ce soit corrigé.
Part d'une session neuve en anglais. Tu fait le sample code qui doit marché de manière normale du coup, puis tu passe ta session en français (réouverture de session pour être sur que tout s'applique) et tu relance l'application.
Détail toute les actions pour le bugreport et ça devrait le faire.
Faut vraiment être précis et livrer le sample code si tu veux que ce soit corrigé.
Pour l'instant BugReporter est en maintenance, j'espère que ce n'est pas moi qui les ai contaminés ;-).
Dans mon rapport j'avais bien écrit de changer les préférences de langue et de fermer/réouvrir la session. J'ai essayé en créant mon appli directement dans un système en anglais que j'utilise parfois quand je veux "penser anglais" et ça fonctionne tout pareil : dès qu'on passe en français la localisation ne comprends pas la virgule et veut un point comme séparateur.
Alors pour l'instant j'attends de voir le résultat de bug-reporter. Hier il y avait un point vert en face du bug rapporté mais je n'en connais pas la signification.
Si nécessaire, la semaine prochaine je pense utiliser un des 2 rapports d'incident offerts avec mon abonnement Developer.
Merci beaucoup du temps que tu m'as consacré.
Ils essaient juste de rattraper le retard. il y a 3 ans j'ai fait un bug report sur un problème d'AppleEvents. j'ai eu confirmation qu'il était en examen et depuis plus RIEN.
Oui mais aussi je suis sur la dernière version "dev" du système en fait, donc je viens de me rendre compte que je ne devrais peut être pas en parler !
ça veut aussi dire que cette version est en perpétuel remaniement et si mon signalement n'est pas le seul ça pourrait aller assez vite. J'ai même l'espoir, quand BugReporter redémarrera, de voir mon bug écarté comme "duplicate".
Il me faut aussi vérifier ce que ça donne avec le 10.9 standard, pour ça j'ai lancé le chargement de Xcode sur mon vieux MacBook mais il ne faut pas être pressé quand on fait ce genre d'installation.
En attendant, une application créé par mon système puis installé et lancée sur le 10.9.1 du MacBook , la dernière version à jour de Mac OS pour tous, présente bien le défaut.
ça y est, BugReporter est réouvert, mon signalement toujours à ouvert et je n'espère donc pas de réponse de Apple avant ... quelque temps.
Mais je me sens moins seul car j'ai découvert "openradar" et un développeur qui a signalé le même problème pour la localisation allemande : http://openradar.appspot.com/15813276 il a aussi ouvert une discussion sur SO : http://stackoverflow.com/questions/21110740/why-does-an-10-4-style-nsnumberformatter-not-auto-localize-decimal-separator
Il faut préciser que le bug vient de l'utilisation dans number formater du behavior "OS X 10.4+ Custom", avec le behavior "OS X 10.4+ Default" il n'y a pas de problème...