GetThreadLocale renvoie une valeur différente de GetUserDefaultLCID?

Question

Pour obtenir les paramètres régionaux, par ex. format de date courte, nous avons toujours utilisé GetLocaleFormatSettings avec GetThreadLocale. Cela a toujours fonctionné sans problème jusqu'à maintenant. Un couple de nos utilisateurs obtiennent des valeurs différentes pour GetThreadLocale qui ne correspondent pas à ce qu'ils ont configuré dans les paramètres régionaux de Windows 7. Nous avons été incapables de reproduire cela, peu importe ce que nous essayons, mais j'ai envoyé un utilisateur un programme de test pour obtenir les informations de locale, et bien sûr GetThreadLocale renvoie un LCID (1033) différent de GetUserDefaultLCID (2057). Ainsi, au lieu d'obtenir les paramètres régionaux UK, ils se retrouvent avec les paramètres régionaux US.

Est-ce que nous obtenons les informations de localisation incorrectement? Devrions-nous utiliser GetUserDefaultLCID au lieu de GetThreadLocale?

Merci

Answer 1

Vous n'êtes pas le seul. Je l'ai vu aussi avec Windows 7 ici en Nouvelle-Zélande et il semble seulement trébucher les applications Delphi pour une raison quelconque pour autant que je sache.

La chose étrange que nous avons trouvée est que le passage à un autre paramètres régionaux via le Panneau de configuration, puis le retour à NZ résout le problème. Je serais curieux de savoir si la même solution de contournement le résout pour vous juste pour vérifier que nous voyons le même phénomène. Je me demande si la sélection de paramètres régionaux non-américains via le processus d'installation de Windows 7 n'est pas tout à fait «correcte» d'une manière subtile qui, pour une raison quelconque, ne fait que trébucher les applications Delphi. Je suis arrivé à un code de test similaire à celui de JP pour essayer de le retrouver et de trouver une solution de contournement mais notre responsable de l'assurance qualité avait trouvé la solution de contournement des paramètres régionaux et n'avait pas vraiment envie de réinstaller Windows 7 encore une fois pour revenir à l'état original funky pour une raison quelconque :-)

Answer 2

j'ai remarqué même problème, quand je commencé à utiliser nouvel ordinateur Windows 7. J'ai passé du temps à essayer de trouver ce qui cause cela, mais je n'ai rien trouvé. J'ai donc simplement ajouté ces deux lignes à certaines sections d'initialisation des unités. Il est étrange que ce comportement ne se produise que sur mon ordinateur, car nous avons également quelques autres ordinateurs Win7 en fonction.

Answer 3

Je viens de tester une nouvelle installation de Windows 7 Starter Edition, et j'ai eu le même problème, mais j'ai trouvé que les paramètres régionaux renvoyés par GetThreadLocale étaient exactement les paramètres régionaux sont corrigés par le programme d'installation de Windows, mais je l'ai changé lors de l'installation par un autre, qui est celui que GetUserDefaultLCID renvoie, aussi celui que je voulais utiliser (j'ai créé un petit programme juste pour ça). Ainsi, les paramètres régionaux ont été modifiés pour l'utilisateur, mais quelque part le premier paramètre régional était toujours spécifié et il a été renvoyé par GetThreadLocale. Comme JP l'a fait remarquer, il y a vraiment un problème avec l'installation, cela ne change pas la localisation à tous les endroits où elle peut être trouvée. Il semble que changer les paramètres régionaux via le Panneau de configuration fait l'affaire bien, et cela pourrait expliquer wy le changer comme proposé fonctionne, d'ailleurs, il explique pourquoi les autres ordinateurs ne pourraient pas avoir le même problème (si vous n'avez pas changé les paramètres locaux installation). Espérons que cette aide.

Answer 4

Pour des informations générales ont un coup d'oeil ici:

http://www.siao2.com/2010/03/19/9980203.aspx

Il semble que ce problème se manifeste sur Vista ainsi que Windows 7.Il se produit parce que Microsoft semble être en train de déprécier le ID de paramètres régionaux en faveur du nom de l'environnement.

En résumé: Les appels d'API pertinents fonctionnent tous sur des valeurs de registre qui peuvent être trouvées à HKCU\Control Panel\International. La valeur "Locale" est conservée pour des raisons de rétrocompatibilité et, dans des circonstances normales, reste synchronisée avec sa contrepartie la plus récente appelée "LocaleName". Ce processus de synchronisation ne fonctionne cependant pas dans certaines circonstances.

Quoi qu'il en soit, l'appel API GetThreadLocale obtient sa valeur de retour de l'entrée de Registre « Locale » mentionné ci-dessus, tandis que les autres (GetUserDefaultLCID, GetSystemDefaultLCID, etc) utilisent l'entrée de Registre « nomlocale ».

D'où la confusion.

BTW, la solution mentionnée par JP in a previous post devrait probablement être étendue à

initialization 
    SetThreadLocale(GetUserDefaultLCID); 
    GetFormatSettings; 

parce que (si je lis correctement!) Selon le Docco l'appel GetUserDefaultLCID représentera personnalisations.

Après un peu plus de recherche, Vista n'est pas affecté du tout. J'ai aussi plus de détails ...

Les appels d'API pertinents fonctionnent tous sur des valeurs de registre qui peuvent être trouvées à HKCU\Control Panel\International. La valeur "Locale" est conservée pour des raisons de compatibilité ascendante et, dans des circonstances normales, est synchronisée avec sa contrepartie plus récente appelée "LocaleName". Sous Windows 7 au moins, ce processus de synchronisation ne fonctionne cependant pas lorsque les processus sont exécutés en tant qu'autre utilisateur (c'est-à-dire, RunAs ou Impersonation). Cela semble être le cas lors de l'installation, où le programme d'installation est lancé à partir d'une session Windows existante. Cela semble toutefois fonctionner correctement si vous avez démarré à partir du CD d'installation.

• GetThreadLocale obtient sa valeur de fil Informations sur le bloc ou le fil de l'environnement Block (TIB ou TEB) Voir: http://en.wikipedia.org/wiki/Thread_Environment_Block Pour les deux Vista et Windows 7, la TIB est initialisée avec l'entrée de Registre HKCU\Control Panel\International\Locale à l'ouverture de session. Cela devient le paramètre régional par défaut pour tous les threads créés pendant la session. La modification de cette valeur de registre au cours d'une session n'a aucun effet sur la valeur renvoyée par l'appel de l'API GetThreadLocale. L'utilisateur doit se déconnecter et se reconnecter pour voir un changement. Il s'agit de l'appel API que Delphi utilise comme base pour initialiser toutes ses chaînes de format de paramètres régionaux (voir la méthode SysUtils.GetFormatSettings), à partir de laquelle tous les champs de date sont mis en forme.

• GetUserDefaultLCID: dans Vista, base sa valeur de retour sur l'entrée de registre HKCU\Control Panel\International\Locale. Dans Windows 7, base sa valeur de retour sur l'entrée de registre HKCU\Control Panel\International\LocaleName. L'entrée de registre respective peut être modifiée pendant une session et le résultat est immédiatement reflété dans cette valeur de retour d'appel d'API.

• SetThreadLocale met à jour le TIB pour refléter les paramètres régionaux fournis dans le paramètre de cet appel. Notez que cela affecte uniquement le thread à partir duquel l'appel d'API est exécuté. Les appels d'API et SetThreadLocale(GetUserDefaultLCID) sont fonctionnellement équivalents. Ils dérivent tous les deux les paramètres régionaux source comme décrit dans l'appel API GetUserDefaultLCID ci-dessus.

Answer 5

Un new post in the RTL forum suggère ce correctif dans SysUtils-> InitSysLocale:

SetThreadLocale(LOCALE_USER_DEFAULT); 
SysLocale.DefaultLCID := LOCALE_USER_DEFAULT; 
GetFormatSettings; 

Et explique en outre:

Il doit être réglé par défaut à LOCALE_USER_DEFAULT et non à 0x409! Ce bogue est en 2010, XE et XE2