softwaremonkey Ответов: 2

Каков рекомендуемый способ синхронизации идентификаторов ресурсов?


У меня есть проект Visual Studio (C++), который использует вспомогательную библиотеку DLL для зависящих от языка ресурсов. Когда я добавляю новый ресурс в основной проект и копирую его в проект satellite DLL, волшебным образом идентификаторам присваивается одно и то же числовое значение, даже если есть два отдельных файла resource.h. Меня бросает в холодный пот при мысли о том, что когда - нибудь в будущем идентификаторам будут присвоены другие значения, и все это рухнет-особенно если мне нужно будет перенумеровать ресурсы.

Нужно ли мне беспокоиться, и если да, то как лучше всего обеспечить, чтобы они всегда оставались неизменными?

Я прочитал несколько интересных статей на этом сайте об этом, но я все еще не понимаю этого.

Что я уже пробовал:

Я попытался включить основной ресурс проекта.h в директивах символов только для чтения спутникового ресурса.h (#include "..\resource.h") но иногда, когда я перестраиваю, компилятор ресурсов изменяет код на что-то, что имеет синтаксическую ошибку в нем (он удаляет обучающую кавычку из включенного файла)

2 Ответов

Рейтинг:
7

KarstenK

Это не магия, а какая-то встроенная функциональность. Вы видите некоторые значения в заголовке ресурса, которые предоставляют эту информацию. Он может идти неправильный - У меня были такие случаи, и их действительно трудно обнаружить. Так что избегайте играть в эту игру. ;-)

Как писал Ричардс, лучше всего использовать только один ресурс.h заголовок. Это подразумевает дисциплину работать только над главным заголовком, а не копировать его в подпроект. Не фергет работать над измененными данными ресурса.

Если вам действительно нужно работать с каким-то краевым случаем, то вы можете использовать файл rc2, который не отслеживается.


softwaremonkey

Спасибо Вам и Ричарду за ваш ответ. Итак, вы говорите, что если я добавлю новый ресурс в основное приложение, а затем скопирую его в библиотеку DLL, то я должен просто "перезаписать" ресурс библиотеки DLL.h с тем, что из основного приложения? Это звучит достаточно легко сделать!

Рейтинг:
15

Rick York

Единственный способ сделать это-иметь значение только в одном заголовке, который включен в обоих местах. Я делаю это, и это хорошо работает для меня, когда я делаю это.

Одна вещь, которую следует учитывать, - это действительно ли идентификаторы ресурсов DLL должны быть видны в файле ресурсов приложения? Я не могу припомнить случая, чтобы они это делали. Я понимаю, что это может сделать некоторые вещи гораздо более удобными, но это не обязательно. Это означает, что вы должны попытаться удалить включение файла Resource.h библиотеки из файла ресурсов приложения. Идентификаторы ресурсов могут быть одинаковыми в DLL и приложении, и есть некоторые функции, которые позволяют выбрать дескриптор для поиска ресурсов, который решает эти проблемы.

In my newer apps I make a special effort to have the resource IDs visible to as few modules as possible. In fact, my dialog handling code does not have any header files. There is an interface defined that does not involve ANY resource IDs. If you think about it, why should there be? Only the specific code that manages the dialog needs them. The code that invokes the dialog doesn't. All it needs to do is call a function and pass it some data and the parent window. The dialog handling code manages all of the data for the app. The app doesn't need to know about every control in the dialog and what type of objects they are or anything else about the dialog like its ID. That doesn't matter to the app because it doesn't use the ID for anything.


softwaremonkey

Спасибо, Ричард. Возможно, я запутал вас своим бессвязным объяснением. Основное приложение не включает в себя файл resource.h библиотеки DLL ресурса, а скорее наоборот. Я сделал это в попытке сохранить идентификаторы одинаковыми, но Visual Studio всегда хочет добавить идентификаторы новых ресурсов в собственный ресурс DLL.h.

Возможно, я пошел по этому неверному пути, но все мои переведенные тексты находятся в Строковой таблице, и поэтому эти идентификаторы должны быть "доступны" довольно большому количеству модулей. Может быть, есть лучший способ?