Здравствуйте, MasterZiv, Вы писали:
MZ>On 05/28/2012 07:28 PM, AlexGin wrote:
>> Допустим, что я сделал по твоему рецепту, то есть написал этот код в таком виде:
>> Здесь я предполагаю, что мы работаем даже не в головном *.exe модуле, а в
>> какой-либо другой (не Telecontrol.dll) библиотеке:
MZ>Это всё равно. AfxSetResourceHandle надо ставить всегда.
Ну а если мы обращаемся к "своему" модулю? То есть в переключении ресурсов нет необходимости.
>> Что будет дальше, когда мы выйдем из данного участка?
>> Хендл ресурсов останется на бибилитотеке Telecontrol.dll, вместо перехода на
>> текущую библиотеку.
MZ>Что такое "текущая библиотека" ?
У меня имеется проект, где есть основной модуль (назовем его MyProg.exe) и примерно 15 модулей *.dll.
Я привел выше код из библиотеки поддержки отображения специальных ситуаций (назовем ее Special.dll) — вот ее я и назвал текущей.
Приведенный мною код характерен для случая, когда библиотеке Special.dll требуется поработать с окнами и ресурсами библиотеки телеуправления (под названием Telecontrol.dll).
>> Наличие хендла на *старой библиотеке* (которая Telecontrol.dll) обеспечит нам
>> дальнейшие грабли
MZ>Нет, если весь код будет правильным, будет соответствовать этим правилам.
MZ>Тут главное понять, что AfxSetResourceHandle надо ставить всегда,
MZ>и надеятся на какую-то "текущую библиотеку" бессмысленно.
MZ>Если это правило соблюдается, то всё будет работать всегда.
+1
Соглашусь, это в действительности будет работать.
ИМХО надеяться на "текущую библиотеку" вполне допустимо.
Конечно при условии, что данный файл *.cpp находится в одном, соответствующем библиотеке, проекте (*.dll или *.exe модуля).
MZ>Другая модель поведения с "текущим активным источником ресурсов" тоже
MZ>конечно же допустима, только возни с ней больше, а толку мало.
Почему же больше возни?
В твоем подходе всюду, где есть использование ресурсов (даже своих), надо ставить AfxSetResourceHandle.
В моем подходе — вмешательство требуется только тогда, когда вызываются окна "чужого" модуля.
MZ>AfxSetResourceHandle() собственно и разрабатывался с заточкой под
MZ>модель с "текущим активным источником ресурсов".
MZ>Ну и если у тебя одно приложение и одна .dll — может оно и хорошо.
MZ>Если модулей несколько сотен, и любой чих может вызвать смену "текущего
MZ>ресурса" -- дело другое.
У меня модулей примерно 15 штук.
Скажем тогда так: любое сознательное обращение к "чужому" модулю, вызывает смену "текущего ресурса"!
Мою подход вообще-то взят не с потолка, он предлагается разными авторами:
http://www.codeguru.com/cpp/cpp/cpp_mfc/tutorials/article.php/c4023/MFC-DLL-TUTORIAL-PART-3.htm
http://www.ucancode.net/Visual_C_MFC_Example/Export-dialog-to-mfc-extension-dll.htm
Разработчики MFC из MS также поддерживает данный подход:
http://msdn.microsoft.com/en-us/library/h5f7ck28%28v=vs.80%29.aspx
...use the functions AfxGetResourceHandle and AfxSetResourceHandle to save the old handle and set the new handle. Be sure to restore the old resource handle before you return to the client application. For an example of using this approach to explicitly load a menu, see Testdll2 .cpp in the MFC sample DLLHUSK.
З.Ы. В общем ясное дело — тема начала переходить в КСВ
И мой и твой подход — имеют право на жизнь.
Применять тот или иной — скорее дело вкуса.