Discussion :

[Maclosky]

Bon il est plutôt rare que j'ai besoin d'aide mais je ne trouve pas d'information sur comment gérer les séparateur de décimal de façon efficace.

Je m'explique avec .NET les calcules se font avec le séparateur ',' et lorsque l'on veux sauvegarder cette valeur dans une base de MySQL le séparateur est '.'. Ma première idée fut de faire un petite bout de code qui convertir le '.' en ',' ou vise versa selon le besoin (sortir des donnée de MySQL et les calculé ou le contraire calculer et mit dans la db), ca fonctionne très bien mais je trouve ca ridicule de devoir appeler ma method pour convertir les séparateur a chaque fois. Il doit bien y avoir un façon plus efficace.

Est-t'il possible de faire en sorte que le . est le séparateur forcer pour tout calcule, comme cela je n'aurai pas a me soucier de MySQL. Se sont des calcule monétaire allant jusqu'à 4 chiffre après la décimal.

J'ai essayé de cette façon mais cela ne fonctionne pas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
string Cn = Thread.CurrentThread.CurrentCulture.Name;
CultureInfo ci = new CultureInfo(Cn);
if (ci.NumberFormat.NumberDecimalSeparator != ".")
{
    ci.NumberFormat.NumberDecimalSeparator = ".";
    Thread.CurrentThread.CurrentCulture = ci;
 }

Donc voila

[François DORIN]

Je m'explique avec .NET les calcules se font avec le séparateur ','

Non. Les calculs en .Net sont indépendant du séparateur, puisque cette notion n'existe tout simplement pas. Le problème qui se pose se présente lors de l'interprétation du chaîne de caractères en tant que float (ou double, ou decimal), où ici, le choix de la culture influence la manière dont la chaîne est interprétée (par exemple, dans des méthodes comme float.Parse ou [c]float.ToString()).

Normalement, tu peux initialiser Thread.CurrentThread.CurrentCulture avec la valeur CultureInfo.InvariantCulture pour obtenir ce que tu souhaites. Tu peux aussi préciser la culture à utiliser dans des méthodes comme Parse ou ToString, qui comprennent des surcharges permettant cela.

Enfin, si le problème se pose pour une communication avec MySQL, je suppose que c'est parce que tu écris des requêtes par concaténation. Généralement, c'est à éviter et il vaut mieux préférer les requêtes paramétrées lorsque c'est possible.

[Maclosky]

J'utilise toujours des requêtes paramétrées. Est ce que tu connais une documentation complète a se sujet ?

Merci pour ton aide.

[François DORIN]

Dans ce cas, lorsque tu initialises ton paramètre, tu lui passe une chaîne de caractère au lieu d'un float ou d'un decimal ? Parce que sinon, tu ne devrais pas avoir de problème de culture...

Et non, je n'ai pas de doc qui traine là dessus. Mais une petite recherche sur Google devrait te donner pas mal de résultats

[Maclosky]

Déjà les informations que tu m'a fournit avec parse ont allumé une lumière. Je viens de tester et je peut faire des calcule avec un . comme séparateur.

Pour MySQL c'est du à la façon dont j'utilise les paramètres ex :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

myCommand.Parameters.AddWithValue("@IdPays", IdPays);

donc le type de donnée n'est pas définit. Le fait que MySQL traite le type decimal en chaine de caractère au lieu de nombre cela cause mon problème.

Est ce que je suis sur le bon chemin ?

[Maclosky]

Petit ajout, est possible que CultureInfo nfi = CultureInfo.InvariantCulture; et CultureInfo nfi = new CultureInfo("en-US"); revient au même vu que InvariantCulture est basé sur "en-US". Y a t-il un avantage a utiliser un ou l'autre ?

[François DORIN]

Pour MySQL c'est du à la façon dont j'utilise les paramètres ex :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

myCommand.Parameters.AddWithValue("@IdPays", IdPays);

donc le type de donnée n'est pas définit. Le fait que MySQL traite le type decimal en chaine de caractère au lieu de nombre cela cause mon problème.

Dans ce cas, essai avec la méthode Add en instanciant manuellement un nouveau paramètre. Tu pourras alors y préciser le type et cela devrait t'éviter d'avoir le soucis.

Petit ajout, est possible que CultureInfo nfi = CultureInfo.InvariantCulture; et CultureInfo nfi = new CultureInfo("en-US"); revient au même vu que InvariantCulture est basé sur "en-US". Y a t-il un avantage a utiliser un ou l'autre ?

Si ma mémoire est bonne, entre les deux, il n'y a aucune différence puisque InvariantCulture est basé sur "en-US". Les deux cultures sont équivalentes fonctionnellement.

Maintenant, il est d'usage

• d'utiliser CultureInfo.InvariantCulture lorsque les besoins de Parse/ToString sont requis pour un stockage, une communication, etc... où il faut que le format soit le même, quelque soit la culture de l'utilisateur (bref, que ce soit invariant)
• d'utiliser "en-US" lorsqu'il s'agit d'interagir avec un utilisateur (parser une entrée, formater correctement un nombre, etc...)