Discussion :

[SergioMaster]

Bonjour,

je me heurte a un petit problème en internationalisation et les dates .

Je force l'affichage des dates dans un DBGrid au format dd.mm.yyyy , jusque là rien de bien difficile , le Hic c'est qu’apparemment la saise dans la Grille ,elle , reste au format local ! embêtant pour notre ami anglophone , l'affichage est bon mais la saisie doit se faire "à l'anglaise" mm.dd.yyyy ce qui est vous vous en doutez , perturbant !

J'ai essayé divers choses mais sans résultats
- changer le ShortdateFormat au niveau de la création de la fiche
- changer ce même format au niveau du source du projet
- changer au niveau du dfm "traduit" ,pour ce petit programme j'ai utilisé l'internationalisation fournie avec delphi (2010 en l'occurence) mais je ne vois vraiment pas où se situerai ce format

une idée ?

[ShaiLeTroll]

Tu ne devrais pas toucher au format manuellement pour l'affichage
laisse ton programme gérer les FormatSettings initialisés par la VCL en fonction de la région en cours !
Un utilisateur anglophone aura une localisation anglaise avec tout ce qui va avec : langue, date, monnaie ...
Idem pour un utilisateur français, laisse l'OS le gérer !

toi en interne, tu dois faire des fonctions au besoin, pour transformer une date format local en format SQL, si tu gères du SQL à la main sans passer par des DBEdit ou DBGrid

[SergioMaster]

Tu ne devrais pas toucher au format manuellement pour l'affichage

Oui , mais non , la date est dans la BDD en DatetimeStamp, et donc , je suis bien obligé de changer le formattage au niveau des champs

laisse ton programme gérer les FormatSettings initialisés par la VCL en fonction de la région en cours !
Un utilisateur anglophone aura une localisation anglaise avec tout ce qui va avec : langue, date, monnaie ...
Idem pour un utilisateur français, laisse l'OS le gérer !

dans un autre soft (pas de date) , mais des ordinateurs français /anglais/etc... j'avais réussi sans soucis a faire que tous le monde est la même devise
(sinon il y avait dollars , francs suisses, euros etc.. selon les postes et sur le même réseau local !!)

en fait , je viens de trouver , pour chaque champ date , il y a bien sur le displayformat , mais il y a aussi le editmask (que je n'avais pas rempli => format par défaut) donc , c'est résolu (du moins pour la partie "urgente")

reste que durant mes tests , avec un petit programme simplifiée , j'ai mis un TDateTimePicker et là , j'ai revu le même comportement mais bon , je ney suis pas allé jusqu'au fond des choses (donc bémol)

[ShaiLeTroll]

Oui , mais non , la date est dans la BDD en DatetimeStamp, et donc , je suis bien obligé de changer le formattage au niveau des champs

DatetimeStamp de quel SGBD ?
DATETIME ou TIMESTAMP, c'est au format de la DB sans lien avec la locale surtout avec du MySQL ou Oracle installé sur un serveur Linux !

Ainsi, deux postes, l'un OS Anglais et l'autres OS Français peuvent accéder aux données, le format de Date DATETIME\TIMESTAMP sera lu tout à correctement et transforme en TDateTime qui est une valeur numérique, ensuite l'affichage des champs TDateField utilise les locales de l'OS en cours, tu n'as pas besoin de le gérer manuellement

le problème c'est qu'avec les DATETIME \ TIMESTAMP, selon le SGBD et le Provider utilisé, cela peut-être géré en TDateField ou TSQLTimeStampField et parfois malheureusement en TStringField

Si TStringField, c'est la qu'intervient une fonction de conversion du format SQL vers le format local
La DB DOIT TOUJOURS utilisé le même format mais tu ne peux pas l'imposer à un utilisateur lambda habitué à ses locales

Si c'est un TDateField, tu devrais vraiment évité les bidouilles, fait confiance à l'OS, et utilise des ParamByName pour les mises à jour, ne manipule pas le SQL à la mano !

Voir OnGetText du TField et OnSetText justement conçu pour l'affichage (DisplayText à true) ou le stockage (DisplayText à false)

dans un autre soft (pas de date) , mais des ordinateurs français /anglais/etc... j'avais réussi sans soucis a faire que tous le monde est la même devise
(sinon il y avait dollars , francs suisses, euros etc.. selon les postes et sur le même réseau local !!)

Heureusement que tu peux t'adapter à la devise de l'utilisateur mais c'est un cas plus complexe, j'ai travaillé sur une application financière, tout était stocké en dollar, en plus, l'utilisateur pouvait avoir l'affichage en monnaie locale et en monnaie du bénéficiaire (dans cette application, c'était souvent du Franc CFA dans ce dernier cas)
La monnaie utilisée dans ce genre d'application est souvent plus globalisé à l'entreprise\compte qu'à la langue de l'OS d'un poste parmi d'autre
En plus le champ Currency ou Float n'est pas typé par la monnaie, peu importe dollar, euro, ... on manipule un chiffre, c'est très différent d'une date stockée\affichée en nombre\chaine avec une grande variabilité de format

en fait , je viens de trouver , pour chaque champ date , il y a bien sur le displayformat , mais il y a aussi le editmask (que je n'avais pas rempli => format par défaut) donc , c'est résolu (du moins pour la partie "urgente")

DisplayFormat, DisplayText va de paire avec OnGetText
EditMask est effectivement indispensable surtout que la modification directement en DBGrid ce n'est pas très ergonomique, mieux vaut un TDBCtrlGrid avec des TDBEdit, c'est un plus agréable et l'on peut y mettre des composants JEDI ou TMS

reste que durant mes tests , avec un petit programme simplifiée , j'ai mis un TDateTimePicker et là , j'ai revu le même comportement mais bon , je ney suis pas allé jusqu'au fond des choses (donc bémol)

TDateTimePicker utilise le format local, ce n'est plus un composant DB, donc encore une fois, on en revient à faire une fonction de conversion du TDateTime vers FormatSQL si l'on génère le SQL à la main ou utilisation de ParamByName qui évite ce genre de soucis