Статья:
Динамическое переключение языка интерфейса в MFC-приложениях

Автор(ы): Илья Зарецкий
Дата: 23.10.2004
Статья рассказывает о реализации механизма переключения языка пользовательского интерфейса в приложениях, разрабатываемых с использованием библиотеки MFC.

Авторы:
Илья Зарецкий

Аннотация:
Статья рассказывает о реализации механизма переключения языка пользовательского интерфейса в приложениях, разрабатываемых с использованием библиотеки MFC.

Здравствуйте, Илья Зарецкий, Вы писали:

ИЗ>Статья:


ИЗ>Авторы:
ИЗ> Илья Зарецкий

ИЗ>Аннотация:
ИЗ>Статья рассказывает о реализации механизма переключения языка пользовательского интерфейса в приложениях, разрабатываемых с использованием библиотеки MFC.

Немного не понятно зачем нужны библиотеки с поддержкой MFC (MFC extension DLL) ?
Чем хуже будут обычные библиотеки ресурсов ?

Здравствуйте, _nn_, Вы писали:

__>Немного не понятно зачем нужны библиотеки с поддержкой MFC (MFC extension DLL) ?

Тем, что в случае использования MFC extension DLL библиотека сама выполняет поиск ресурсов по всем загруженным модулям, избавляя нас от явных вызовов SetResourceHandle().

Здравствуйте, SchweinDeBurg, Вы писали:

SDB>Здравствуйте, _nn_, Вы писали:

__>>Немного не понятно зачем нужны библиотеки с поддержкой MFC (MFC extension DLL) ?

SDB>Тем, что в случае использования MFC extension DLL библиотека сама выполняет поиск ресурсов по всем загруженным модулям, избавляя нас от явных вызовов SetResourceHandle().

Зато в случае ресурсов вообще не нужно выполнять никакого кода со стороны библиотеки (DLL).

Здравствуйте, _nn_, Вы писали:

__>Здравствуйте, SchweinDeBurg, Вы писали:

SDB>>Здравствуйте, _nn_, Вы писали:

__>>>Немного не понятно зачем нужны библиотеки с поддержкой MFC (MFC extension DLL) ?

SDB>>Тем, что в случае использования MFC extension DLL библиотека сама выполняет поиск ресурсов по всем загруженным модулям, избавляя нас от явных вызовов SetResourceHandle().

__>Зато в случае ресурсов вообще не нужно выполнять никакого кода со стороны библиотеки (DLL).

Так и здесь никого кода со стороны extension DLL не выполняется (кроме простенькой однократной инициализации при загрузке). Под "библиотекой" я в предыдущем посте подразумевал MFC.

Здравствуйте, SchweinDeBurg, Вы писали:

SDB>Здравствуйте, _nn_, Вы писали:

__>>Здравствуйте, SchweinDeBurg, Вы писали:

SDB>>>Здравствуйте, _nn_, Вы писали:

__>>>>Немного не понятно зачем нужны библиотеки с поддержкой MFC (MFC extension DLL) ?

SDB>>>Тем, что в случае использования MFC extension DLL библиотека сама выполняет поиск ресурсов по всем загруженным модулям, избавляя нас от явных вызовов SetResourceHandle().

__>>Зато в случае ресурсов вообще не нужно выполнять никакого кода со стороны библиотеки (DLL).

SDB>Так и здесь никого кода со стороны extension DLL не выполняется (кроме простенькой однократной инициализации при загрузке).
Вот эту инициализацию можно исключить полностью, вдобавок это сделает возможным использование DLL в программах написанных без MFC без проблем.
SDB>Под "библиотекой" я в предыдущем посте подразумевал MFC.

Здравствуйте, _nn_, Вы писали:

SDB>>Так и здесь никого кода со стороны extension DLL не выполняется (кроме простенькой однократной инициализации при загрузке).
__>Вот эту инициализацию можно исключить полностью, вдобавок это сделает возможным использование DLL в программах написанных без MFC без проблем.

Безусловно. Но код инициализации пишется один раз (или вообще генерится Колдуном), а вызов SetResourceHandle() (с запоминанием предыдущего дескриптора и его последующим восстановлением) придется выполнять многократно — если часть ресурсов (общая для всех языков) содержится в основном исполняемом модуле.

Думаю, что нашу с Вами дискуссию можно закрыть (по крайней мере — публичную), поскольку предложенный мной в стаье способ ориентирован в первую и главную очередь именно на приложения, создаваемые с использованием MFC (а Вы, как мы оба знаем — большой поклонник WTL ). При желании продолжить — мы друг у друга в контактах...

Здравствуйте, SchweinDeBurg, Вы писали:

SDB>Думаю, что нашу с Вами дискуссию можно закрыть (по крайней мере — публичную), поскольку предложенный мной в стаье способ ориентирован в первую и главную очередь именно на приложения, создаваемые с использованием MFC (а Вы, как мы оба знаем — большой поклонник WTL ). При желании продолжить — мы друг у друга в контактах...
Честно говоря возникло несколько проблем:
описание VC6, MDI-проект MFC 6, пробовал на вин98
1) насколько я уловил из Круглински MFC extension позволяет следующее
если загружена библиотека расгирения, ресурс одназначно будет грузиться из длл (без SetResourceHandle и зависимостей от языка текущего)
такого у меня не произошло
2) без явного вызова SetResourceHandle исполняемый модуль упорно грузил из себя
3) setlocale — не помогала в решении задачи
4) код смены меню, никуда не годиться для CMDIFrameWnd, получалось белиберда — но это решаемо, просто не до копал.

Что хотел бы:
основной модуль содержит все ресурсы (к примеру русские), а вот некая длл (extension или resource only) содержит на другом языке. В присутствии длл программа локализована (ищет автоматом, или как то можно указать в опциях — не принципиально), в отсуствуии работает только на том, который есть в исполняемом файле.
Именно это в общем то и не получилось, все в конце концов сводилось к явному вызову SetResourceHandle

Здравствуйте, Carc, Вы писали:

C>Честно говоря возникло несколько проблем:
C>описание VC6, MDI-проект MFC 6, пробовал на вин98

Прошу прощения за поздний ответ — проглядел Ваш пост, поскольку топик слишком быстро уехал вниз.

Давайте начнем вот с чего: пример, прилагающийся к статье, работает на Вашей системе правильно?

C>1) насколько я уловил из Круглински MFC extension позволяет следующее
C>если загружена библиотека расгирения, ресурс одназначно будет грузиться из длл C>(без SetResourceHandle и зависимостей от языка текущего)

Нет, это не так. Позволю себе маленькую цитату:

...ядро MFC при явной (например, CMenu::LoadMenu) или неявной (например, CDialog::DoModal) загрузке любого ресурса ищет его не только в том модуле, дескриптор которого возвращает функция AfxGetResourceHandle, но и во всех extension DLLs, загруженных в адресное пространство процесса.

При этом поиск ресурса по цепочке загруженных extension DLLs осуществляется только в том случае, если требуемый ресурс не был найден в исполняемом модуле. Замечу, что это утверждение имеет несколько упрощенный характер и справедливо в том случае, если после запуска приложения мы не вызывали явно функцию AfxSetResourceHandle(). Если быть точным до конца, то

When looking for a resource, most of the standard MFC implementations that load resources look first at the current resource module (AfxGetResourceHandle) and if not found walk the list of CDynLinkLibrary objects attempting to load the requested resource.

C>такого у меня не произошло
C>2) без явного вызова SetResourceHandle исполняемый модуль упорно грузил из себя
C>3) setlocale — не помогала в решении задачи

Что естественно — см. выше.

C>4) код смены меню, никуда не годиться для CMDIFrameWnd, получалось белиберда — но это решаемо, просто не до копал.

Согласен, для MDI понадобится доработка, займусь.

Здравствуйте, SchweinDeBurg, Вы писали:

SDB>Здравствуйте, Carc, Вы писали:

C>>Честно говоря возникло несколько проблем:
C>>описание VC6, MDI-проект MFC 6, пробовал на вин98

SDB>Прошу прощения за поздний ответ — проглядел Ваш пост, поскольку топик слишком быстро уехал вниз.

SDB>Давайте начнем вот с чего: пример, прилагающийся к статье, работает на Вашей системе правильно?
хм... пример то общем то простой, и есстественно разибираясь, просто начал применять... проверю!

C>>1) насколько я уловил из Круглински MFC extension позволяет следующее
C>>если загружена библиотека расгирения, ресурс одназначно будет грузиться из длл C>(без SetResourceHandle и зависимостей от языка текущего)

SDB>Нет, это не так. Позволю себе маленькую цитату:

SDB>

SDB>...ядро MFC при явной (например, CMenu::LoadMenu) или неявной (например, CDialog::DoModal) загрузке любого ресурса ищет его не только в том модуле, дескриптор которого возвращает функция AfxGetResourceHandle, но и во всех extension DLLs, загруженных в адресное пространство процесса.

SDB>При этом поиск ресурса по цепочке загруженных extension DLLs осуществляется только в том случае, если требуемый ресурс не был найден в исполняемом модуле. Замечу, что это утверждение имеет несколько упрощенный характер и справедливо в том случае, если после запуска приложения мы не вызывали явно функцию AfxSetResourceHandle(). Если быть точным до конца, то

SDB>

SDB>When looking for a resource, most of the standard MFC implementations that load resources look first at the current resource module (AfxGetResourceHandle) and if not found walk the list of CDynLinkLibrary objects attempting to load the requested resource.

C>>такого у меня не произошло
C>>2) без явного вызова SetResourceHandle исполняемый модуль упорно грузил из себя
C>>3) setlocale — не помогала в решении задачи

SDB>Что естественно — см. выше.
Окей! Уточню дома у Круглински с точностью до цитаты.

C>>4) код смены меню, никуда не годиться для CMDIFrameWnd, получалось белиберда — но это решаемо, просто не до копал.

SDB>Согласен, для MDI понадобится доработка, займусь.
Ну это то в целом не проблема, я думаю разобраться не сложно. Просто руки не дошли.
Спасибо за ответ.

Здравствуйте, Илья Зарецкий, Вы писали:

ИЗ>Статья рассказывает о реализации механизма переключения языка пользовательского интерфейса в приложениях, разрабатываемых с использованием библиотеки MFC.
Хорошая статья. Спасибо!

Сам этой схемой пользуюсь уже больше года в своей программе. Посему могу сказать каковы минусы и плюсы. То что локализация сделана не по убогому принципу INI файлов — это несомненный плюс, который дает возможность избежать проблем с такими вещами как разница в ширине исходного и переведенного текста, например в том же диалоге. За примером ходить далеко не надо — немецкий язык тому яркое подтверждение Половина строк просто потом невлазит. Естественно, что наличие самого темлейта диалога в ресурсах языковой dll решает проблему. Просто взяли и растянули диалог и выправили контролы на нем. Если еще например взять языки в которых текст читается справа-налево — тоже проблем вообщем-то нет. В ресурсах направление и layout можно подправить. Вообщем гораздо лучше, чем INI, правда?

Но есть и обратная сторона медали Проблема начинается при росте программы от версии к версии. "Руками" отслеживать все изменения в этих библиотеках очень сложно. Фактически приходится переписывать ее заново. И если замена (или отсутствие) в новой версии очередной строки в ресурсах дело не столь щипитильное, то отсутствие какого-либо контрола на диалоге (в новой версии он есть, и что самое главное есть код в приложении, который предпологает его наличие, а в старой версии его нет) делает программу неработоспособной на предыдущей версии ресурсов. И если полное отсутствие диалога в новых ресурсах спасает тем, что по умолчанию подгрузится default из самого приложения, то какое-либо несоответствие приводит к плачевным последствиям. Вывод — неизменной единицей в ресурсах является уже не просто строка, а целый диалог, меню и т.д., что само по себе усложняет процесс сопровождения.

Best regards,
Николай

Здравствуйте, Nikeware, Вы писали:

N>Здравствуйте, Илья Зарецкий, Вы писали:

ИЗ>>Статья рассказывает о реализации механизма переключения языка пользовательского интерфейса в приложениях, разрабатываемых с использованием библиотеки MFC.
N>Хорошая статья. Спасибо!

N>Сам этой схемой пользуюсь уже больше года в своей программе. Посему могу сказать каковы минусы и плюсы. То что локализация сделана не по убогому принципу INI файлов — это несомненный плюс, который дает возможность избежать проблем с такими вещами как разница в ширине исходного и переведенного текста, например в том же диалоге. За примером ходить далеко не надо — немецкий язык тому яркое подтверждение Половина строк просто потом невлазит. Естественно, что наличие самого темлейта диалога в ресурсах языковой dll решает проблему. Просто взяли и растянули диалог и выправили контролы на нем. Если еще например взять языки в которых текст читается справа-налево — тоже проблем вообщем-то нет. В ресурсах направление и layout можно подправить. Вообщем гораздо лучше, чем INI, правда?

N>Но есть и обратная сторона медали Проблема начинается при росте программы от версии к версии. "Руками" отслеживать все изменения в этих библиотеках очень сложно. Фактически приходится переписывать ее заново. И если замена (или отсутствие) в новой версии очередной строки в ресурсах дело не столь щипитильное, то отсутствие какого-либо контрола на диалоге (в новой версии он есть, и что самое главное есть код в приложении, который предпологает его наличие, а в старой версии его нет) делает программу неработоспособной на предыдущей версии ресурсов. И если полное отсутствие диалога в новых ресурсах спасает тем, что по умолчанию подгрузится default из самого приложения, то какое-либо несоответствие приводит к плачевным последствиям. Вывод — неизменной единицей в ресурсах является уже не просто строка, а целый диалог, меню и т.д., что само по себе усложняет процесс сопровождения.
Рехех.... ну может тогда не такой уж убогий "принцип ини-файлов"?

А какие-нить идеи были как бороться с отсутствием контрола на диалоге (а код есть), я в общем то ничего толкового и не придумал так!?! Ну конечно можно контролировать все GetDlgItem и т.д., но все равно не выход, очень замусоривается код, причем даже не столько проверками, сколько сообщения что мол ошибка.
Да и не всегда понятно, какое решение лучше — позволить программе дохромать (ну если не удалось найти контрол через GetDlgItem то просто не выполнять с ним никаких действий), или же все таки дать программе с треском рухнуть — зато юзермессадж на эту тему гарантирован, и тогда ошибка будет исправлена...

N>Best regards,
N>Николай

Здравствуйте, Carc, Вы писали:

C>Рехех.... ну может тогда не такой уж убогий "принцип ини-файлов"?
Универсальных средств не бывает. И у каждого есть свои плюсы и минусы. Вышеизложенный способ намного гибче и предоставляет гораздо больше возможностей. INI еще нужно "протащить" через весь код, занимаясь переводом каждой формы на лету, а это дополнительный код(!). Здесь же достаточно загрузки ресурсов в одном единственном месте кода при старте программы. Дальше просто "забыли" и все.

C>А какие-нить идеи были как бороться с отсутствием контрола на диалоге (а код есть), я в общем то ничего толкового и не придумал так!?! Ну конечно можно контролировать все GetDlgItem и т.д., но все равно не выход, очень замусоривается код, причем даже не столько проверками, сколько сообщения что мол ошибка.
C>Да и не всегда понятно, какое решение лучше — позволить программе дохромать (ну если не удалось найти контрол через GetDlgItem то просто не выполнять с ним никаких действий), или же все таки дать программе с треском рухнуть — зато юзермессадж на эту тему гарантирован, и тогда ошибка будет исправлена...
У меня есть одно прекрасное средство, которым я всегда пользуюсь — ASSERT() называется Оно Вам нужно, "контролировать все GetDlgItem"? Это называется, создадим себе проблем, а потом будем с ними бороться. Зачем писать совершенно ненужный код, который правит подобные ошибки. Это лишнее. Проще недопускать подобных ситуаций. А вот чтобы их не допускать, хотелось бы иметь некое средство (программу), которое позволяло бы управлять и синхронизировать ресурсы с учетом многоязыковой поддержки. Хотелось то всего лишь, чтобы:
— было понятие проекта с такой еденицей, как исходный оригинальный ресурсный файл (dll, rc), желательно даже с пониманием dsp проектов;
— было создание на основе оригинального ресурса других ресурсных едениц (трансляций), которые и будут являться теми самыми переводами;
— программа могла при изменении оригинального ресурса (вышла новая/очередная версия программы) показывать изменения и позволять синхронизировать эти изменения с ресурсами-трансляциями. Мечтаю видеть окно, разделенно пополам, в одной части диалог/форма старой версии в другом тот, что сейчас изменился в оригинальном ресурсе и драг-анд-дроп. Взял и из нового перетащил недостающее в старый. Такое же и для меню и всего остально, что можно по такому принципу представить.

При таком подходе достаточно один раз пройтись по переводам, сделать синхронизацию, отослать на доперевод трансляции авторам и пересобрать заново ресурсы.

На диссертацию не тянет, но на идею для шаровары само то

Best regards,
Николай

>Рехех.... ну может тогда не
> такой уж убогий "принцип ини-файлов"?

Как человек, использующий ини-файлы в аналогичном приложении, подтверждаю — "золотой пули" здесь нет (хотя ини все-таки не такие уж и убогие ) Каждый подход имеет свои плюсы и минусы. Более того, я все-больше убеждаюсь что перевод должны делать специалисты, а не пользователи, а первые вполне могут справится с более сложным окружением для перевода.

Здравствуйте, Nikeware, Вы писали:

N>Здравствуйте, Carc, Вы писали:

C>>Рехех.... ну может тогда не такой уж убогий "принцип ини-файлов"?
N>Универсальных средств не бывает. И у каждого есть свои плюсы и минусы. Вышеизложенный способ намного гибче и предоставляет гораздо больше возможностей. INI еще нужно "протащить" через весь код, занимаясь переводом каждой формы на лету, а это дополнительный код(!). Здесь же достаточно загрузки ресурсов в одном единственном месте кода при старте программы. Дальше просто "забыли" и все.
Была идея да руки не дошли — API Hooking — перехватывать загрузку ресурса и грузить их из ини (к примеру, может это вообще быть какой-нить xml) а если во внешнем файле (ини, xml) не найден ресурс — тогда уж грузить из ресурсов файла.

C>>А какие-нить идеи были как бороться с отсутствием контрола на диалоге (а код есть), я в общем то ничего толкового и не придумал так!?! Ну конечно можно контролировать все GetDlgItem и т.д., но все равно не выход, очень замусоривается код, причем даже не столько проверками, сколько сообщения что мол ошибка.
C>>Да и не всегда понятно, какое решение лучше — позволить программе дохромать (ну если не удалось найти контрол через GetDlgItem то просто не выполнять с ним никаких действий), или же все таки дать программе с треском рухнуть — зато юзермессадж на эту тему гарантирован, и тогда ошибка будет исправлена...
N>У меня есть одно прекрасное средство, которым я всегда пользуюсь — ASSERT() называется Оно Вам
Речь не о том: ASSERT то работает в Debug c моей версией ресурсов, а проблема появится в Release c библиотекой ресурсов которую могет быть Вася Пупкин писал... и там или есть или нету контрола X...., а ситуация более чем реальная, когда приложение модифицируется достаточно часто. Вот к примеру в том же Windows Commander четко видно, что он локализует иногда не все (т.е. явно что видимо ресурсы от старой версии) — но все же хоть что-то. "Еду как могу". Имхо это лучше, все таки он не падает из за ошибки Васи Пупкина — тем более что пользователь не умрет от того что-то то лишнее в диалоге.

нужно, "контролировать все GetDlgItem"? Это называется, создадим себе проблем, а потом будем с ними бороться. Зачем писать совершенно ненужный код, который правит подобные ошибки. Это лишнее. Проще недопускать подобных ситуаций. А вот чтобы их не допускать, хотелось бы иметь некое средство (программу), которое позволяло бы управлять и синхронизировать ресурсы с учетом многоязыковой поддержки. Хотелось то всего лишь, чтобы:
N>- было понятие проекта с такой еденицей, как исходный оригинальный ресурсный файл (dll, rc), желательно даже с пониманием dsp проектов;
N>- было создание на основе оригинального ресурса других ресурсных едениц (трансляций), которые и будут являться теми самыми переводами;
N>- программа могла при изменении оригинального ресурса (вышла новая/очередная версия программы) показывать изменения и позволять синхронизировать эти изменения с ресурсами-трансляциями. Мечтаю видеть окно, разделенно пополам, в одной части диалог/форма старой версии в другом тот, что сейчас изменился в оригинальном ресурсе и драг-анд-дроп. Взял и из нового перетащил недостающее в старый. Такое же и для меню и всего остально, что можно по такому принципу представить.

N>При таком подходе достаточно один раз пройтись по переводам, сделать синхронизацию, отослать на доперевод трансляции авторам и пересобрать заново ресурсы.

N>На диссертацию не тянет, но на идею для шаровары само то
Угу, я бы тоже хотел такое увидеть — но все что я видел честно говоря вызывало ощущение — Шлеп, хлоп и поехали. "Так и я могу" &#169 Промокашка.
Написать конечно можно попробовать, но там одной "черной" работы немало, поэтому в одиночку мне кажется это сложновато сделать. А собственно 99.9 того чего не хватало мне в этих чудах, Вы описали. Но видимо писать все же придется


N>Best regards,
N>Николай

Здравствуйте, Carc, Вы писали:

C>Была идея да руки не дошли — API Hooking — перехватывать загрузку ресурса и грузить их из ини (к примеру, может это вообще быть какой-нить xml) а если во внешнем файле (ини, xml) не найден ресурс — тогда уж грузить из ресурсов файла.
Повторюсь — в обсуждаемом способе ничего изобретать не нужно, уже все есть.
Попутно вспомнил. А что Вы будете с Юникодом делать? Я сколько видел Ini, там все сплошь ANSI

C>Речь не о том: ASSERT то работает в Debug c моей версией ресурсов, а проблема появится в Release c библиотекой ресурсов которую могет быть Вася Пупкин писал... и там или есть или нету контрола X...., а ситуация более чем реальная, когда приложение модифицируется достаточно часто. Вот к примеру в том же Windows Commander четко видно, что он локализует иногда не все (т.е. явно что видимо ресурсы от старой версии) — но все же хоть что-то. "Еду как могу". Имхо это лучше, все таки он не падает из за ошибки Васи Пупкина — тем более что пользователь не умрет от того что-то то лишнее в диалоге.
"Вам шашешки или ехать?" (с) Эдак можно допрограммироватьтся и получить монстра на 99,9% процентов состоящего из кода, который сам себя правит от вмешательства извне. Терминатор-2 внатуре Должна быть разумная граница. Для меня это ASSERT и если какой-то Пупкин залез и без прочтения инструкции "наложил" в коде, то "ССЗБ". На сайте для этого все есть(должно быть) — инструкция по применению + инструмент. Я об инструменте и веду речь. Сейчас они отсутствуют (я не видел во всяком случае нормальных). Были бы нормальные инструменты, работащие в рамках данной парадигмы, было бы все нормально. Если хотите, рассматривайте любую программу как некий ограничитель действий пользователя Давая пользователю делать только то, что разрешено в определенный момент времени, вы тем самым программируете логику программы и тем самым получаете ожидаемый результат. Как пример, БД. Если бы все лазили без ведома в файлы базы данных напрямую (для лучшего понимания представим что это просто текстовые файлы), то был бы полный капец. Поэтому и пишется нечто, называемое СИСТЕМОЙ УПРАВЛЕНИЯ БД (в обсуждаемом контексте — Система Ограничения Доступа по вполне определенной логике). Просто нужно заставить Васю играть по правилам Поверьте, это легче, чем сидет и думать, где он в этот раз "наложит".

C>Угу, я бы тоже хотел такое увидеть — но все что я видел честно говоря вызывало ощущение — Шлеп, хлоп и поехали. "Так и я могу" &#169 Промокашка.
Если Вы видите "Так и я могу", то точно так уже не напишите, как минимум чуть лучше

C>Написать конечно можно попробовать, но там одной "черной" работы немало, поэтому в одиночку мне кажется это сложновато сделать. А собственно 99.9 того чего не хватало мне в этих чудах, Вы описали. Но видимо писать все же придется
Вас пугают сложности? "Нам расколоть его поможет... !" (с)

Best regards,
Николай

Здравствуйте, Nikeware, Вы писали:

N>Здравствуйте, Carc, Вы писали:

C>>Была идея да руки не дошли — API Hooking — перехватывать загрузку ресурса и грузить их из ини (к примеру, может это вообще быть какой-нить xml) а если во внешнем файле (ини, xml) не найден ресурс — тогда уж грузить из ресурсов файла.
N> Повторюсь — в обсуждаемом способе ничего изобретать не нужно, уже все есть.
N>Попутно вспомнил. А что Вы будете с Юникодом делать? Я сколько видел Ini, там все сплошь ANSI
ну к промеру ини, может быть и вообще что-то иное... тут я просто не подумал

C>>Речь не о том: ASSERT то работает в Debug c моей версией ресурсов, а проблема появится в Release c библиотекой ресурсов которую могет быть Вася Пупкин писал... и там или есть или нету контрола X...., а ситуация более чем реальная, когда приложение модифицируется достаточно часто. Вот к примеру в том же Windows Commander четко видно, что он локализует иногда не все (т.е. явно что видимо ресурсы от старой версии) — но все же хоть что-то. "Еду как могу". Имхо это лучше, все таки он не падает из за ошибки Васи Пупкина — тем более что пользователь не умрет от того что-то то лишнее в диалоге.
N>"Вам шашешки или ехать?" (с) Эдак можно допрограммироватьтся и получить монстра на 99,9% процентов состоящего из кода, который сам себя правит от вмешательства извне. Терминатор-2 внатуре Должна быть разумная граница. Для меня это ASSERT и если какой-то Пупкин залез и без прочтения инструкции "наложил" в коде, то "ССЗБ". На сайте для этого все есть(должно быть) — инструкция по применению + инструмент. Я об инструменте и веду речь. Сейчас они отсутствуют (я не видел во всяком случае нормальных). Были бы нормальные инструменты, работащие в рамках данной парадигмы, было бы все нормально. Если хотите, рассматривайте любую программу как некий ограничитель действий пользователя Давая пользователю делать только то, что разрешено в определенный момент времени, вы тем самым программируете логику программы и тем самым получаете ожидаемый результат. Как пример, БД. Если бы все лазили без ведома в файлы базы данных напрямую (для лучшего понимания представим что это просто текстовые файлы), то был бы полный капец. Поэтому и пишется нечто, называемое СИСТЕМОЙ УПРАВЛЕНИЯ БД (в обсуждаемом контексте — Система Ограничения Доступа по вполне определенной логике). Просто нужно заставить Васю играть по правилам Поверьте, это легче, чем сидет и думать, где он в этот раз "наложит".
пожалуй Вы правы, всем не угодишь

C>>Угу, я бы тоже хотел такое увидеть — но все что я видел честно говоря вызывало ощущение — Шлеп, хлоп и поехали. "Так и я могу" &#169 Промокашка.
N>Если Вы видите "Так и я могу", то точно так уже не напишите, как минимум чуть лучше
ну я надеюсь, ей богу сколько видел чего-только не было, и в эксель толкаем, и интерфейс красивый. Одна проблема — не едут лыжи. Имхо все эта "экселевщина" ни к чем, это можно приделать и потом. А вот движок нада делать умный.

C>>Написать конечно можно попробовать, но там одной "черной" работы немало, поэтому в одиночку мне кажется это сложновато сделать. А собственно 99.9 того чего не хватало мне в этих чудах, Вы описали. Но видимо писать все же придется
N>Вас пугают сложности? "Нам расколоть его поможет... !" (с)
Меня пугают не сложности как раз, а скорее время... и то что такой проект в одиночку никогда не закончить. А сами сложности, так это же прекрасно мозги поразмять.

N>Best regards,
N>Николай

Здравствуйте, Nikeware, Вы писали:

C>>Рехех.... ну может тогда не такой уж убогий "принцип ини-файлов"?

N>Универсальных средств не бывает. И у каждого есть свои плюсы и минусы. Вышеизложенный способ намного гибче и предоставляет гораздо больше возможностей. INI еще нужно "протащить" через весь код, занимаясь переводом каждой формы на лету, а это дополнительный код(!). Здесь же достаточно загрузки ресурсов в одном единственном месте кода при старте программы. Дальше просто "забыли" и все.

Отлично, при старте приложения мы может его локализовать. А как быть с динамическим переключением языка, про которое идет речь в статье и на тему которого приведен пример? Я сам пользуюсь убогими ини-файлами и сейчас рассматриваю вопрос о том, стоит ли сменить подход к локазизации.
Итак, вопрос: У меня есть dialog-based приложение с кучей загруженных контролов и дочерних диалогов. В примере к статье при смене языка происходит перезагрузка меню. Соответственно мне на лету придется перезагрузить все диалоги, правильно?

Если я не прав, то, пожалуйста, поясните механизм по которому произойдет смена языка на загруженных диалогах.

Здравствуйте, <Аноним>, Вы писали:

А> Итак, вопрос: У меня есть dialog-based приложение с кучей загруженных контролов и дочерних диалогов. В примере к статье при смене языка происходит перезагрузка меню. Соответственно мне на лету придется перезагрузить все диалоги, правильно?

Если эти диалоги видны на экране — да. Точнее, придется прибить диалоги, перегрузить DLL с ресурсами, а потом эти диалоги пересоздать.