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

Vi2>Например, %MODULE% в файле регистрации (где-то был мой пост на эту тему. Ты же у нас сыщик, найдешь) укажет верный путь. Вводишь свое ключевое слово, ATL-скриптер будет заменять все его вхождения в теле скрипта.
Замена UpdateRegistry в классе

Автор: ilya123
Дата: 22.01.03

    static HRESULT WINAPI UpdateRegistry(BOOL bRegister)
    {
        _ATL_REGMAP_ENTRY yourMapEntries[] = {
            { L"ProgID", someVarWithProgID },
            { L"ClsID", someVarWithCLSID }, // в формате L"{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}"
            {NULL,NULL}};
        return _Module.UpdateRegistryFromResource(IDR_***, bRegister,yourMapEntries);
    }

И rgs файл

HKCR
{
    %ProgID%.x.1 = s 'x Class'
    {
        CLSID = s '%ClsID%'
    }
    %ProgID%.x = s 'x Class'
    {
        CLSID = s '%ClsID%'
        CurVer = s '%ProgID%.x.1'
    }
    NoRemove CLSID
    {
        ForceRemove %ClsID% = s 'x Class'
        {
...

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

Kaa>Привет.
В Win2000 и выше есть такая фичка как Side-By-Side execution — если этот Com с расширением не Dll а local лежит в каталоге с exe-шником то подбирается он

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

Kaa>Решается ли эта проблема заменой пары строк в файлах проекта? Нужно ли для каждого свой проект создавать? ... и так далее.

Нет, не нужно. Есть масса способов сделать твою фишку.

Например, %MODULE% в файле регистрации (где-то был мой пост на эту тему. Ты же у нас сыщик, найдешь) укажет верный путь. Вводишь свое ключевое слово, ATL-скриптер будет заменять все его вхождения в теле скрипта.

Или DECLARE_REGISTRY(class, pid, vpid, nid, flags) макрос.

Или же дополнительные, вставляемые в свою UpdateRegistry, вызовы CComModule::RegisterProgID при регистрации минимального скрипта — только CLSID. Вставив тело DECLARE_REGISTRY_RESOURCEID в класс и добавив новый вызов.

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

Kaa>А кто и откуда будет звать эту функцию UpdateRegistry()?

Эта функция используется при описаниии кокласса в Карте Объектов сервера:

#define OBJECT_ENTRY(clsid, class) {&clsid, class::UpdateRegistry, ...

И вызывается при регистрации/дерегистрации сервера — при -RegServer/-UnregServer для EXE и DllRegisterServer/DllUnregisterServer для DLL.

Привет.

Есть набор COM-объктов, лежащих в одной DLL, и имеющий имена somename.ifacename.N.

Содержимое бинаря зависит от набора макросов, и разные реализации олжны использоваться в разных приложениях. Нет проблем, пока 2 таких приложения с разной конфигурацией не приходится использовать на одной машине.

Вопрос: как, сделав минимальное количество телодвижений, изменzть ProgID для всех объектов в библиотеке? Типа, сделать Lib1.COM1 -> Lib2.COM1

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

Kaa>Есть набор COM-объктов, лежащих в одной DLL, и имеющий имена somename.ifacename.N.
Kaa>Содержимое бинаря зависит от набора макросов, и разные реализации олжны использоваться в разных приложениях. Нет проблем, пока 2 таких приложения с разной конфигурацией не приходится использовать на одной машине.
Kaa>Вопрос: как, сделав минимальное количество телодвижений, изменить ProgID для всех объектов в библиотеке? Типа, сделать Lib1.COM1 -> Lib2.COM1

ProgID для объектов в DLL хранится в скрипте регистрации и используется только при регистрации. Больше о нем упоминания нет.

Нетрудно сделать скрипт регистрации, меняющий ProgID регистрации. Однако дело-то в GUID-ах, которые не меняются при замене ProgID. Ну изменишь ты ProgID объекта. Но он ссылается на CLSID, который-то и определяет объект. А он не изменился. Следовательно, старый будет затерт или использован неправильно.

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

Vi2>Ну изменишь ты ProgID объекта. Но он ссылается на CLSID, который-то и определяет объект.
Это понятно: "Все дело в пузырьках". Я написал ProgID в надежде, что все понятно

Мне надо заменить весь комплекс: и прогид, и классид. Чтоб реализация у объекта осталась прежней, но собрать его можно было легко в другую DLL (с другим именем), чтоб он стал доступен по другому ProgID (соответственно, надо _И_ CLSID сменить), и при этом никто не умер

Короче, мне нужно плодить объекты, отличающиеся ProgID, CLSID, имеющие идентичную реализацию снаружи, но со скрытыми и фатальными различиями внутри.

Пример от фонаря:
Объекты должен читать данные. Способ чтения и тип источника задается на этапе компиляции (собственно, весь огород из-за этого). Так вот. Я хочу, чтобы чтение из файла осуществлял объект с именем FileReader.reader, а из таблицы базы данных — DBReader.reader.

Сама реализация объекта не изменяется. Изменяется только набор прилинковываемых к нему статических библиотек. И городится огород для того, чтоб не было попыток открыть один сорс другим объектом.

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

Немного переформулирую.

Есть хранилище с набором объектов. Нужно быстро (почти на лету) менять то, что в прогиде до первой точки, в зависимости от настроек условной компиляции.

Решается ли эта проблема заменой пары строк в файлах проекта? Нужно ли для каждого свой проект создавать? ... и так далее.

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

А кто и откуда будет звать эту функцию UpdateRegistry()?

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

К сожалению, не пашет этот способ у меня (пока), хотя и в MSDN ему я подтверждение нашел. ( Наверное, лыжи не едут, или что. При наличии в .rgs какого-либо своего заменителя + UpdateRegistry регистрация завершается с 0x80020009 == Exception occured. А где и почему он occored — фиг его знает. При сгенеренном .rgs-е (в нем только %MODULE% из переменных) — все нормально регистрируется.

Создал Simple object, добавил функцию в правильное место, изменил rgs. Что не так? VC6 SP5.

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

[]

Ты, все-таки, поставь бряку на AtlModuleUpdateRegistryFromResourceD.

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

Полезно, но не в этот раз. Нужна 98 совместимость.