SHBrowseForFolder with localization for a specific language
我使用SHBrowseForFolder API在Windows中显示文件夹选择对话框。我的应用程序支持基于最终用户选择的UI语言本地化。这是通过使用FindResourceEx API加载特定LCID的所有资源来实现的。
所以我很好奇,有什么办法可以让SHBrowseForFolder荣誉线程的LCID选择?或者,以其他方式使它根据LCID显示我的首选语言的文本?
- 这是一个Windows对话框。您的用户可以轻松识别它,它会说自己的语言。如果您需要本地化的屏幕截图,则获取MSDN或Windows Ultimate的许可证,以便获得语言包。
-
@HansPassant:他们不会感到困难,它看起来很糟糕。说,我的Windows用户界面语言是英语。最终用户将我的应用程序的UI更改为德语,但是此对话框仍以英语显示窗口标题,"取消"按钮,"新文件夹"按钮。在这种情况下,我需要用德语显示它。
-
该德语用户将拥有Windows的德语版本。如果他不是出于某种奇怪的原因,那么他将非常熟悉使用另一种语言进行的对话,那么他每天都会使用它。实际上,他会认为您的看起来很奇怪。
-
@HansPassant:这个问题与我的应用程序UI的实现无关。
-
否。这是Windows对话框。我似乎一遍又一遍地重复自己。
-
@HansPassant:该对话框由我的应用程序显示,这是最终用户将与之关联的对话框。没有人关心它的来源。
AFAIK,SHBrowseForFolder()本身不是用户可本地定位的。您要在对话框中准确定位哪些文本?您必须为其提供标题,以便提供所需的任何预本地化文本。
您是否正在尝试本地化按钮标题或其他控件?为此,您必须使用回调功能来手动访问和操作对话框控件。
看看切换到IFileOpenDialog界面。至少具有SetFileNameLabel()和SetOkButtonLabel()方法。
- 在最佳情况下,我希望所有UI都已本地化。但我明白你的意思。我可能必须手动进行。谢谢。
只是好奇,谁在投票呢?你们不在乎本地化吗?
尽管如此,我想我找到了解决方案。它是在一个单独的线程上向我提出的,它是为MessageBox API设计的C#项目,但是概念是相同的。在使用SetWindowsHookEx(WH_CALLWNDPROCRET)调用SHBrowseForFolder之前,请安装线程范围的钩子,然后从钩子过程中捕获WM_INITDIALOG通知。从那里只需根据UI语言加载本地化的文本,然后使用SetDlgItemText将其设置为控件,其中hDlg =您在挂钩过程中获得的窗口句柄,而nIDDlgItem =需要本地化的按钮和文本字段的ID。这是当前使用的按钮:IDOK ="确定"按钮,IDCANCEL ="取消"按钮,0x3746 ="新建文件夹"按钮。您还可以通过在窗口句柄上调用SetWindowText来更改浏览窗口本身的标题。然后,当SHBrowseForFolder返回时,调用UnhookWindowsHookEx从其摘机。
这种方法有一些缺点。其一是它依靠MS来保持浏览窗口的布局。到目前为止,它一直是相对相同的。因此,您可能希望使用GetVersionEx跟踪Windows版本并进行相应调整。
第二,您可能需要在添加新文本之后调整按钮和标签的大小。但幸运的是,这不是问题。将DrawText与DT_CALCRECT标志一起使用以查看新标签的轮廓,然后使用MoveWindow更改每个控件的大小。请注意,更复杂的方法将涉及完全调整浏览窗口本身的大小。但我将由您决定。
最后,我要说的是,微软在证明其UI的本地化方法方面如此means脚实在可惜。据说有一些API旨在做到这一点,仅举几例:
-
SetThreadLocale-老实说,我不知道它到底是做什么的,目的是什么。该文档接近白痴。
-
SetThreadUILanguage-尽管已在Windows XP中引入,但此API仅从Windows Vista开始起作用。但是,它仍然仅将UI的80%设置为提供的LCID。例如,SHBrowseForFolder不受它的影响,但是可能还会更多。我没有检查其他常用控件。
-
InitMUILlanguage-我不知道这个东西是做什么的。它对我的应用没有影响...
-
setlocale-仅影响诸如printf之类的传统C语言。不过,这些都没有用于UI。
所以你去了。从技术上讲,它们都不起作用。因此,一个开发人员被迫为Windows编写(并相信我,我会尽快避免使用它),该开发人员希望为最终用户提供从其程序中更改UI语言的功能,而无需诉诸繁琐的Windows用户范围内的更改的语言,剩下来设计自己的方式。微软进展顺利!
最后,是上面@HansPassant建议的内容。我不能让我的用户为能够在我的应用的用户界面中使用他们的语言而支付100美元。对不起,但我不能跌得这么低...