GetThreadLocale返回的值与GetUserDefaultLCID不同？

Question

为了获得语言环境设置,例如短日期格式,我们总是使用GetLocaleFormatSettings和GetThreadLocale.到目前为止,这一直没有问题.

我们的几个用户获得的GetThreadLocale值与Windows 7中的区域设置中的配置值不同.无论我们尝试什么,我都无法重现这一点,但我向一位用户发送了测试用于获取区域设置信息的程序,并且足够确定GetThreadLocale返回与GetUserDefaultLCID(2057)不同的LCID(1033).因此,它们不是获取英国语言环境设置,而是最终使用美国语言环境设置.

我们是否错误地获取了区域设置信息？我们应该使用GetUserDefaultLCID而不是GetThreadLocale吗？

谢谢

Answer 1

有些背景信息请看这里:

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

因此,似乎这个问题在Vista和Windows 7上都有所体现.这是因为Microsoft似乎正在弃用Locale ID以支持Locale Name.

总结一下:相关的API调用都可以在可以找到的注册表值上运行HKCU\Control Panel\International.值" Locale "是为了向后兼容性而维护的,并且在正常情况下与其名为" LocaleName "的新对应方保持同步.然而,这种同步过程在某些情况下不起作用.

总之,GetThreadLocaleAPI调用从"获取其返回值区域设置上面提到的"注册表项,而其他(GetUserDefaultLCID,GetSystemDefaultLCID,等)使用" LocaleName "注册表项.

因此混乱.

顺便说一下,JP在上一篇文章中提到的解决方案应该可以延伸到

initialization
  SetThreadLocale(GetUserDefaultLCID);
  GetFormatSettings;

因为(如果我正确地读它!)根据docco,GetUserDefaultLCID调用将考虑用户自定义.

经过一番研究,Vista根本没有受到影响.我也有更多细节......

相关的API调用都可以在可以找到的注册表值上运行HKCU\Control Panel\International.值"Locale"是为了向后兼容性而维护的,并且在正常情况下与其名为"LocaleName"的新对应方保持同步.至少在Windows 7下,这个同步过程不能在以另一个用户(即RunAs或模拟)运行进程的情况下工作.在安装过程中似乎就是这种情况,安装程序从现有的Windows会话启动.但是,如果您从安装CD启动,它似乎可以正常工作.

• GetThreadLocale从线程信息块或线程环境块(TIB或TEB)获取其值请参阅:http://en.wikipedia.org/wiki/Thread_Environment_Block 对于Vista和Windows 7,HKCU\Control Panel\International\Locale 在登录时使用注册表项初始化TIB .这将成为会话期间创建的所有线程的默认区域设置.在会话期间更改此注册表值不会影响GetThreadLocale API调用返回的值.用户必须注销并再次登录才能看到更改.这是Delphi用作初始化其所有语言环境格式字符串(请参阅SysUtils.GetFormatSettings方法)的基础的API调用,从中调用所有日期字段.

• GetUserDefaultLCID:在Vista中,将其返回值基于HKCU\Control Panel\International\Locale注册表项.在Windows 7中,将其返回值基于HKCU\Control Panel\International\LocaleName注册表项.可以在会话期间更改相应的注册表项,结果会立即反映在此API调用返回值中.

• SetThreadLocale更新TIB以反映此调用的参数中提供的区域设置.请注意,这只会影响执行API调用的线程.API调用SetThreadLocale(LOCALE_USER_DEFAULT)并且SetThreadLocale(GetUserDefaultLCID)功能相同.它们都导出源语言环境,如GetUserDefaultLCID上面的API调用中所述.

Answer 2

你并不是唯一的一个.我在新西兰的Windows 7中也看到了这一点,据我所知,它似乎只是出于某些原因而绊倒了Delphi应用程序.

我们发现的奇怪的事情是通过控制面板切换到不同的区域设置然后切换回NZ解决了这个问题.我很想知道相同的解决方法是否能解决它只是为了验证我们是否看到了同样的现象.

我想知道是否通过Windows 7安装过程选择非美国区域设置并不是以某种微妙的方式"做正确的事情",因为某些原因只会使Delphi应用程序绊倒.

我已经到了JP的类似测试代码,试图追踪它并找到一个软件解决方法,但我们的QA家伙后来发现'区域设置切换器'的解决方法,他不想再完全重新安装Windows 7以取回由于某种原因,到原始的时髦状态:-)

Answer 3

当我开始使用新的Windows 7计算机时,我注意到了同样的问题.我花了一些时间试图找到导致这种情况的原因,但一无所获.所以我只是将这两行添加到某些单元初始化部分.

initialization
  SetThreadLocale(LOCALE_USER_DEFAULT);
  GetFormatSettings;

奇怪的是,这种行为只发生在我的电脑上,因为我们办公室里的其他Win7电脑也很少.