"DenProg" <75187@users.rsdn.ru> сообщил/сообщила в новостях следующее: news:3143157@news.rsdn.ru...
> Здравствуйте, Carc, Вы писали:
>
> C>В ДЛЛ очень легко напороться на то что в ДЛЛ одна версия интерфейса, а в EXE уже другой код, который расчитан на другой UI. Причем это не то что бы "легко", а просто это уже со версии 0.00 build 2 начнется — проверено. И поймать это невозможно формальными методами (или по крайней мере весьма непросто). В DLL ресурс лежит под одним ID, а в коде обозначен другой. Причем ловить это можно только в runtime со 100% покрытием кода.
>
> Возможно. В том числе элеменарным поиском по ID в коде. Зато когда всех переловишь, куда проще будет.
Поиск по ID... О да! Я не спорю, некоторые вещи конечно можно найти, я иногда сам специально так делаю: изменить ID в resource h и все пересобрать — нехай компилятор сам трудицца, буду еще в сотнях строк искать. Тут Вы, конечно же правы. Но опишу другую вполне реальную ситуацию.
Есть у нам главное меню вида: к примеру "Вставка\Шаблоны\Сами списки_шаблонов" и подменю "Сами списки_шаблонов" формируется динамически, заполняется ну какими-либо пользовательскими шаблонами. Найти такое подменю можно ТОЛЬКО по menu pos position, т.к. у popup-меню нету никакого ID. Т.е. код будет искать по каким то магическим числа, из серии второе слева (Вставка), потом 3 сверху (Шаблоны) ну и т.д.
Понимаете кудя я клоню. Никакой поиск ID тут не поможет, его в принципе нет. Безусловно в Debug версии можно еще и ASSERTAми забить все, проверять ID соседних пунктов в меню "Вставка" — исключительно для контроля в Debug версии, что более менее в меню попали. Но все равно на этапе Икс Вы обязаны будете выбирать меню именно по позиции. Так что 100% гарантии это не даст.
Ну? Убедил? Ситуация вполне возможная (пример реальный, из живиого проекта, только немного урезал для простоты — )

> C>Но это еще не всё ((C) барон Мюнхаузен). Протестя одну ДЛЛ, это вообще ничего не значит с другой языковой ДЛЛ, можете начинать 100% покрытие кода в связке с другой ДЛЛ заново.
> C>Для большого проекта, да где еще не один язык это не приемлемо. Будем без конца гонять ДЛЛ, код вообще заморозится навсегда.
>
> Если DLL однотипные (как и должно быть), проблем не будет.
Почему не будет то? Не понял Вас... Выше описал суть:

> В варианте с текстовым файлом ресурсов (каким впрочем и является RC-файл) есть такая закорюка. Пусть есть диалог. На диалоге есть строки. Строки переводятся. Одна и та же строка в разных языках будет иметь разную длину. Если диалоговый ресурс один, а строка в разных вариантах перевода имеет разную длину, она попросту может не уместиться на диалоге.
Ну согласитесь со мной, это вполне реально и в других способах локализации. Длина строк, тут ничего не попишешь: обычно для этого предусматривается некоторый запас. Хотя есть вполне успешные проекты, где на это положили "ананас" (Total Commander, с не родным языком, + пошалить с настройками шрифтов).