TN057. Локализация компонентов MFC
Примечание.
Следующее техническое примечание не было обновлено, поскольку сначала оно было включено в электронную документацию. В результате некоторые процедуры и разделы могут быть устаревшими или неверными. Для получения последних сведений рекомендуется выполнить поиск интересующей темы в алфавитном указателе документации в Интернете.
В этом примечании описываются некоторые конструкции и процедуры, которые можно использовать для локализации компонента, если это приложение или элемент управления OLE или библиотека DLL, использующая MFC.
Обзор
При локализации компонента, использующего MFC, существует две проблемы. Во-первых, необходимо локализовать собственные ресурсы — строки, диалоги и другие ресурсы, относящиеся к вашему компоненту. Большинство компонентов, созданных с помощью MFC, также включают и используют ряд ресурсов, определенных MFC. Кроме того, необходимо предоставить локализованные ресурсы MFC. К счастью, несколько языков уже предоставляются самим MFC.
Кроме того, компонент должен быть готов к выполнению в целевой среде (европейская или dbCS-включенная среда). В большинстве случаев это зависит от того, как приложение обрабатывает символы с высоким набором битов правильно и обрабатывает строки с двойными байтами. MFC включен по умолчанию для обеих этих сред, таким образом, что во время установки можно использовать один двоичный файл по всему миру, используемый на всех платформах с просто разными ресурсами, подключенными во время установки.
Локализация ресурсов компонента
Локализация приложения или библиотеки DLL должна включать простое замена ресурсов ресурсами, соответствующими целевому языку. Для собственных ресурсов это относительно просто: измените ресурсы в редакторе ресурсов и создайте приложение. Если код написан правильно, не будет строк или текста, которые вы хотите локализовать жестко закодированный в исходный код C++ — все локализации можно сделать, просто изменив ресурсы. На самом деле вы можете реализовать компонент таким образом, что все, предоставляющие локализованную версию, даже не включают сборку исходного кода. Это более сложно, но хорошо стоит это и является механизмом, выбранным для самого MFC. Кроме того, можно локализовать приложение, загрузив EXE или DLL-файл в редактор ресурсов и непосредственно изменив ресурсы. Хотя это возможно, требуется повторное применение этих изменений при каждом создании новой версии приложения.
Один из способов избежать этого заключается в поиске всех ресурсов в отдельной библиотеке DLL, иногда называемой вспомогательной библиотекой DLL. Затем эта библиотека DLL загружается динамически во время выполнения, а ресурсы загружаются из этой библиотеки DLL, а не из основного модуля со всем кодом. MFC напрямую поддерживает этот подход. Рассмотрим приложение с именем MYAPP.EXE; Он может иметь все свои ресурсы, расположенные в библиотеке DLL с именем MYRES.DLL. В приложении InitInstance
будет выполняться следующее, чтобы загрузить библиотеку DLL и вызвать загрузку ресурсов MFC из этого расположения:
CMyApp::InitInstance()
{
// one of the first things in the init code
HINSTANCE hInst = LoadLibrary("myres.dll");
if (hInst != NULL)
AfxSetResourceHandle(hInst);
// other initialization code would follow
// ...
}
После этого MFC загружает ресурсы из этой библиотеки DLL вместо myapp.exe. Однако все ресурсы должны присутствовать в этой библиотеке DLL; MFC не будет искать экземпляр приложения в поиске заданного ресурса. Этот метод применяется одинаково хорошо к обычным библиотекам DLL MFC, а также к элементам управления OLE. Программа установки будет копировать соответствующую версию MYRES.DLL в зависимости от того, какой языковой стандарт ресурса пользователь хотел бы.
Это относительно простое создание только библиотеки DLL ресурсов. Создайте проект DLL, добавьте свой. Rc-файл в него и добавьте необходимые ресурсы. Если у вас есть существующий проект, который не использует этот метод, можно скопировать ресурсы из этого проекта. После добавления файла ресурса в проект вы почти готовы к сборке проекта. Единственное, что необходимо сделать, — задать параметры компоновщика для включения /NOENTRY. Это сообщает компоновщику, что библиотека DLL не имеет точки входа, так как она не имеет кода, у нее нет точки входа.
Примечание.
Редактор ресурсов в Visual C++ 4.0 и более поздних версий поддерживает несколько языков на каждый. RC-файл. Это позволяет легко управлять локализацией в одном проекте. Ресурсы для каждого языка управляются директивами препроцессора, созданными редактором ресурсов.
Использование предоставленных локализованных ресурсов MFC
Любое приложение MFC, которое вы создаете, повторно использует две вещи из MFC: код и ресурсы. То есть MFC содержит различные сообщения об ошибках, встроенные диалоги и другие ресурсы, используемые классами MFC. Чтобы полностью локализовать приложение, необходимо локализовать не только ресурсы приложения, но и ресурсы, поступающие непосредственно из MFC. MFC предоставляет несколько разных файлов ресурсов языка автоматически, поэтому если целевой язык является одним из языков, уже поддерживаемых MFC, необходимо просто убедиться, что эти локализованные ресурсы используются.
По состоянию на этот текст MFC поддерживает китайский, немецкий, испанский, французский, итальянский, японский и корейский. Файлы, содержащие эти локализованные версии, находятся в каталогах MFC\INCLUDE\L.* (L) для локализованных каталогов. Например, немецкие файлы находятся в MFC\INCLUDE\L.DEU. Чтобы приложение использовало эти RC-файлы вместо файлов, расположенных в MFC\INCLUDE, добавьте /IC:\PROGRAM FILES\MICROSOFT VISUAL STUDIO .NET 2003\VC7\MFC\INCLUDE\L.DEU
в командную строку RC (это просто пример; вам потребуется заменить языковой стандарт, а также каталог, в который вы установили Visual C++).
Приведенные выше инструкции будут работать, если приложение статически связывается с MFC. Большинство приложений динамически связываются (так как это appWizard по умолчанию). В этом сценарии код динамически связан не только с ресурсами. В результате вы можете локализовать ресурсы в приложении, но ресурсы реализации MFC по-прежнему будут загружены из MFC7x.DLL (или более поздней версии) или из MFC7xLOC.DLL, если она существует. Вы можете приблизиться к этому с двух разных углов.
Более сложный подход заключается в том, чтобы отправить один из локализованных библиотек MFC7xLOC.DL (например, MFC7xDEU, для германии, MFC7xESP.DLL для испанского языка и т. д.), или более поздней версии, а также установить соответствующую версию MFC7xLOC.DLL в системный каталог при установке приложения пользователем. Это может быть очень сложно как для разработчика, так и для конечного пользователя, и как это не рекомендуется. Дополнительные сведения об этом методе и его предостережениях см . в техническом примечание 56 .
Самый простой и безопасный подход заключается в том, чтобы включить локализованные ресурсы MFC в приложение или библиотеку DLL (или ее спутниковую библиотеку DLL при использовании). Это позволяет избежать проблем, связанных с установкой MFC7xLOC.DLL. Для этого выполните те же инструкции, что и для статического регистра, указанного выше (задание командной строки RC правильно указывать на локализованные ресурсы), за исключением того, что необходимо также удалить /D_AFXDLL
определение, которое было добавлено AppWizard. При /D_AFXDLL
определении AFXRES. H (и другие ФАЙЛЫ RC MFC) фактически не определяют ресурсы (так как они будут извлечены из библиотек DLL MFC).
См. также
Технические примечания по номеру
Технические примечания по категории