Если описание поместить в билиотеку,
то компилятор НЕ генерит proxy заглушки. Вопрос — почему? И как его
заставить генерить их.
Может, то что помещено в билиотеку имеет какие-то свои proxy
заглушки и не стоит об этом беспокоиться?
Re: определение интерфесов в IDL файле
От:
Аноним
Дата:
24.09.03 09:11
Оценка:
Здравствуйте, dima_gf, Вы писали:
_>При создании idl файла, определения интерфейсов можно _> поместить как в блок библиотеки library:
_>library DDD _>{ _> [...] _> interface d1 : IUnknown {...}; _>};
_>так и перед библиотекой:
_>[...] _>interface d1 : IUnknown{...};
_>library DDD _>{ _>};
_>Если описание поместить в билиотеку, _>то компилятор НЕ генерит proxy заглушки. Вопрос — почему? И как его _>заставить генерить их. _>Может, то что помещено в билиотеку имеет какие-то свои proxy _>заглушки и не стоит об этом беспокоиться?
Я не большой спец в MIDL, но насколко знаю, все, что объявляется внутри оператора library, не будет учитываться при генерации файлов с определениями типов С++. Помещение объявления внутрь оператора library говорит о том, что этот тип будет скомпилирован в библиотеку типов. Однако его не обязательно явно определять внутри. Достаточно, чтобы внутри оператора library была ссылка на этот тип, ин он будет включен.
Так что при создании сових библиотек просто старайся описывать типы вне оператора library, это может пригодиться
Здравствуйте, dima_gf, Вы писали:
_>При создании idl файла, определения интерфейсов можно _> поместить как в блок библиотеки library:
_>library DDD _>{ _> [...] _> interface d1 : IUnknown {...}; _>};
_>так и перед библиотекой:
_>[...] _>interface d1 : IUnknown{...};
_>library DDD _>{ _>};
_>Если описание поместить в билиотеку, _>то компилятор НЕ генерит proxy заглушки. Вопрос — почему? И как его _>заставить генерить их. _>Может, то что помещено в билиотеку имеет какие-то свои proxy _>заглушки и не стоит об этом беспокоиться?
Что значит не генерит? Очень даже генерит. Может просто ты не включал интерфейс в кокласс, тогда вполне возможно, что не генерит. А вобще очень важно как описан интерфейс точно. Например наличие атрибута oleautomation говорит, что используется стандартная ps.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, dima_gf, Вы писали:
_>>При создании idl файла, определения интерфейсов можно _>> поместить как в блок библиотеки library:
_>>library DDD _>>{ _>> [...] _>> interface d1 : IUnknown {...}; _>>};
_>>так и перед библиотекой:
_>>[...] _>>interface d1 : IUnknown{...};
_>>library DDD _>>{ _>>};
_>>Если описание поместить в билиотеку, _>>то компилятор НЕ генерит proxy заглушки. Вопрос — почему? И как его _>>заставить генерить их. _>>Может, то что помещено в билиотеку имеет какие-то свои proxy _>>заглушки и не стоит об этом беспокоиться?
А>Я не большой спец в MIDL, но насколко знаю, все, что объявляется внутри оператора library, не будет учитываться при генерации файлов с определениями типов С++. Помещение объявления внутрь оператора library говорит о том, что этот тип будет скомпилирован в библиотеку типов. Однако его не обязательно явно определять внутри. Достаточно, чтобы внутри оператора library была ссылка на этот тип, ин он будет включен.
А>Так что при создании сових библиотек просто старайся описывать типы вне оператора library, это может пригодиться
Списибо за ответ. Но дело в том, что при опиании интерфейса перед библиотекой — производится вставка описания интерфеса в заголовочнв\ый файл — что не всегда удобно — а именно, когда приходится ссылаться на другие интерфейсы. При этом могут получиться перекрестные ссылки и переопределеня интерфесов. Если все описывать внутри библиотеки — то можно очень комфортно использовать директиву import — без проблем.
Здравствуйте, DrMom, Вы писали:
DM>Здравствуйте, dima_gf, Вы писали:
_>>При создании idl файла, определения интерфейсов можно _>> поместить как в блок библиотеки library:
_>>library DDD _>>{ _>> [...] _>> interface d1 : IUnknown {...}; _>>};
_>>так и перед библиотекой:
_>>[...] _>>interface d1 : IUnknown{...};
_>>library DDD _>>{ _>>};
_>>Если описание поместить в билиотеку, _>>то компилятор НЕ генерит proxy заглушки. Вопрос — почему? И как его _>>заставить генерить их. _>>Может, то что помещено в билиотеку имеет какие-то свои proxy _>>заглушки и не стоит об этом беспокоиться?
DM>Что значит не генерит? Очень даже генерит. Может просто ты не включал интерфейс в кокласс, тогда вполне возможно, что не генерит. А вобще очень важно как описан интерфейс точно. Например наличие атрибута oleautomation говорит, что используется стандартная ps.
Спасибо за ответ. не генерит — значит не генрит — вот пример когда генерится заглушка:
Здравствуйте, dima_gf, Вы писали:
_>Здравствуйте, DrMom, Вы писали:
DM>>Здравствуйте, dima_gf, Вы писали:
_>>>При создании idl файла, определения интерфейсов можно _>>> поместить как в блок библиотеки library:
_>>>library DDD _>>>{ _>>> [...] _>>> interface d1 : IUnknown {...}; _>>>};
_>>>так и перед библиотекой:
_>>>[...] _>>>interface d1 : IUnknown{...};
_>>>library DDD _>>>{ _>>>};
_>>>Если описание поместить в билиотеку, _>>>то компилятор НЕ генерит proxy заглушки. Вопрос — почему? И как его _>>>заставить генерить их. _>>>Может, то что помещено в билиотеку имеет какие-то свои proxy _>>>заглушки и не стоит об этом беспокоиться?
DM>>Что значит не генерит? Очень даже генерит. Может просто ты не включал интерфейс в кокласс, тогда вполне возможно, что не генерит. А вобще очень важно как описан интерфейс точно. Например наличие атрибута oleautomation говорит, что используется стандартная ps.
Здравствуйте, dima_gf, Вы писали:
_>Здравствуйте, DrMom, Вы писали:
DM>>Здравствуйте, dima_gf, Вы писали:
_>>>При создании idl файла, определения интерфейсов можно _>>> поместить как в блок библиотеки library:
_>>>library DDD _>>>{ _>>> [...] _>>> interface d1 : IUnknown {...}; _>>>};
_>>>так и перед библиотекой:
_>>>[...] _>>>interface d1 : IUnknown{...};
_>>>library DDD _>>>{ _>>>};
_>>>Если описание поместить в билиотеку, _>>>то компилятор НЕ генерит proxy заглушки. Вопрос — почему? И как его _>>>заставить генерить их. _>>>Может, то что помещено в билиотеку имеет какие-то свои proxy _>>>заглушки и не стоит об этом беспокоиться?
DM>>Что значит не генерит? Очень даже генерит. Может просто ты не включал интерфейс в кокласс, тогда вполне возможно, что не генерит. А вобще очень важно как описан интерфейс точно. Например наличие атрибута oleautomation говорит, что используется стандартная ps.
Ну так, на сколько я понимаю, для этого интерфейса и не надо генерить заглушку. Здесь ведь все типы стандартные. Просто запускаешь nmake -f *.mak и все. Может я чего не понял, то просьбы пояснить.
ЗЫ И еще я снова не понял, что значит не генерится заглушка? Типа даже сишные файлы не создаются? Сейчас попробую.
Здравствуйте, DrMom, Вы писали:
DM>Здравствуйте, dima_gf, Вы писали:
_>>Здравствуйте, DrMom, Вы писали:
DM>>>Здравствуйте, dima_gf, Вы писали:
_>>>>При создании idl файла, определения интерфейсов можно _>>>> поместить как в блок библиотеки library:
_>>>>library DDD _>>>>{ _>>>> [...] _>>>> interface d1 : IUnknown {...}; _>>>>};
_>>>>так и перед библиотекой:
_>>>>[...] _>>>>interface d1 : IUnknown{...};
_>>>>library DDD _>>>>{ _>>>>};
_>>>>Если описание поместить в билиотеку, _>>>>то компилятор НЕ генерит proxy заглушки. Вопрос — почему? И как его _>>>>заставить генерить их. _>>>>Может, то что помещено в билиотеку имеет какие-то свои proxy _>>>>заглушки и не стоит об этом беспокоиться?
DM>>>Что значит не генерит? Очень даже генерит. Может просто ты не включал интерфейс в кокласс, тогда вполне возможно, что не генерит. А вобще очень важно как описан интерфейс точно. Например наличие атрибута oleautomation говорит, что используется стандартная ps.
_>>#include iobj.idl;
_>> [ _>> uuid(989AB07A-26A1-4333-8595-6C6A6469BCFF), _>> helpstring("GF_AlarmClock Class") _>> ] _>> coclass GF_AlarmClock _>> { _>> [default] interface IGF_AlarmClockDisp; _>> [default, source] dispinterface _IGF_Events; _>> interface IGF_AlarmClock; _>> interface IGF_Object; _>> }; _>>};
_>>------------------------------------------------------------------------
DM>Ну так, на сколько я понимаю, для этого интерфейса и не надо генерить заглушку. Здесь ведь все типы стандартные. Просто запускаешь nmake -f *.mak и все. Может я чего не понял, то просьбы пояснить.
DM>ЗЫ И еще я снова не понял, что значит не генерится заглушка? Типа даже сишные файлы не создаются? Сейчас попробую.
Спасибо за участие.
По поводу стандартных типов — дело в том, что заглушка генерируется и для них (если посмотреть результирующий
сишный файл). А не генерится — именно сишные файлы. Др. словами все что указано за библиотекой — проксится (не зависимо от типа параметров).
Вот что получается по приведенной функции:
Здравствуйте, DrMom, Вы писали:
DM>Здравствуйте, dima_gf, Вы писали:
_>>Здравствуйте, DrMom, Вы писали:
DM>>>Здравствуйте, dima_gf, Вы писали:
_>>>>При создании idl файла, определения интерфейсов можно _>>>> поместить как в блок библиотеки library:
_>>>>library DDD _>>>>{ _>>>> [...] _>>>> interface d1 : IUnknown {...}; _>>>>};
_>>>>так и перед библиотекой:
_>>>>[...] _>>>>interface d1 : IUnknown{...};
_>>>>library DDD _>>>>{ _>>>>};
_>>>>Если описание поместить в билиотеку, _>>>>то компилятор НЕ генерит proxy заглушки. Вопрос — почему? И как его _>>>>заставить генерить их. _>>>>Может, то что помещено в билиотеку имеет какие-то свои proxy _>>>>заглушки и не стоит об этом беспокоиться?
DM>>>Что значит не генерит? Очень даже генерит. Может просто ты не включал интерфейс в кокласс, тогда вполне возможно, что не генерит. А вобще очень важно как описан интерфейс точно. Например наличие атрибута oleautomation говорит, что используется стандартная ps.
_>>#include iobj.idl;
_>> [ _>> uuid(989AB07A-26A1-4333-8595-6C6A6469BCFF), _>> helpstring("GF_AlarmClock Class") _>> ] _>> coclass GF_AlarmClock _>> { _>> [default] interface IGF_AlarmClockDisp; _>> [default, source] dispinterface _IGF_Events; _>> interface IGF_AlarmClock; _>> interface IGF_Object; _>> }; _>>};
_>>------------------------------------------------------------------------
DM>Ну так, на сколько я понимаю, для этого интерфейса и не надо генерить заглушку. Здесь ведь все типы стандартные. Просто запускаешь nmake -f *.mak и все. Может я чего не понял, то просьбы пояснить.
DM>ЗЫ И еще я снова не понял, что значит не генерится заглушка? Типа даже сишные файлы не создаются? Сейчас попробую.
Не генерится ни сишный файл ни dll. А работаю я из оболчки VC 7.
_>Хотя — по поводу стандартности парамкетров я не подумал, впрочем зачем тогда генерировать?
Незачем. Все и так работать будет. Обычно озаглушке вспоминают тогда когда методы с нестандартными параметрами выпоняться перестают. (сам так все время вспоминаю)
Здравствуйте, DrMom, Вы писали:
DM>Здравствуйте, dima_gf, Вы писали:
_>>Хотя — по поводу стандартности парамкетров я не подумал, впрочем зачем тогда генерировать?
DM>Незачем. Все и так работать будет. Обычно озаглушке вспоминают тогда когда методы с нестандартными параметрами выпоняться перестают. (сам так все время вспоминаю)
Да уж, нафилиздипил я здесь... Вобщем так. Если все параметры стандартные, то используй атрибут oleautomation и не парься с заглушкой. Если нет, то заглушка нужна. Вот почему сишные файлы не генерятся это для меня загадка, т.к. использование объектов становится возможным только в пределах одного апартамента. Вобще я всегда описывал интерфейсы за приделами библиотеки, т.к. давно сталкивался с этой проблемой. Тогда я выяснил, что если на интерфейс нет ссылок в library XXXLib, то и в библиотеку типов он не попадет.
Здравствуйте, DrMom, Вы писали:
DM>Здравствуйте, dima_gf, Вы писали:
_>>Хотя — по поводу стандартности парамкетров я не подумал, впрочем зачем тогда генерировать?
DM>Незачем. Все и так работать будет. Обычно озаглушке вспоминают тогда когда методы с нестандартными параметрами выпоняться перестают. (сам так все время вспоминаю)
Согласен. Но что же делать с НЕСТАНДАРТНЫМИ данными — они же тоже не "озаглушиваются". Тогда придется думать — какие у тебя данные — стандартные или нет. Хотя все эти рассуждения не имеют смысла. Факт остается — почему-то не строятся заглушки — это вы тоже поняли.
Здравствуйте, dima_gf, Вы писали:
_>При создании idl файла, определения интерфейсов можно _> поместить как в блок библиотеки library:
_>library DDD _>{ _> [...] _> interface d1 : IUnknown {...}; _>};
_>так и перед библиотекой:
_>[...] _>interface d1 : IUnknown{...};
_>library DDD _>{ _>};
_>Если описание поместить в билиотеку, _>то компилятор НЕ генерит proxy заглушки. Вопрос — почему? И как его _>заставить генерить их. _>Может, то что помещено в билиотеку имеет какие-то свои proxy _>заглушки и не стоит об этом беспокоиться?
А вот я например сделал PS для такого файла:
// MIDLTest.idl : IDL source for MIDLTest.dll
//
// This file will be processed by the MIDL tool to
// produce the type library (MIDLTest.tlb) and marshalling code.import "oaidl.idl";
import "ocidl.idl";
[
uuid(D9EC3169-EFAA-42B8-B731-EE244D566D34),
version(1.0),
helpstring("MIDLTest 1.0 Type Library")
]
library MIDLTESTLib
{
importlib("stdole32.tlb");
importlib("stdole2.tlb");
[
object,
uuid(89E8C244-75BE-41F2-BA08-B4D3492533E5),
helpstring("IObj Interface"),
pointer_default(unique)
]
interface IObj : IUnknown
{
[propget, helpstring("property Func")] HRESULT Func([out, retval] long *pVal);
[propput, helpstring("property Func")] HRESULT Func([in] long newVal);
};
[
uuid(4C7F475E-5D7E-4AFF-B437-D619520EFA4E),
helpstring("Obj Class")
]
coclass Obj
{
[default] interface IObj;
};
};
Вобщем я так понимаю, что мой VC6 глючит и от раза к разу если тосовать idl файл то генерит, то нет заглушку. Вот такая вот фигня. Кстати у меня еще ни всегда генерится заглушка в противоположенном варианте! Причем я все время перекомпилю библиотеку заново и удаляю все файлы компилера (сишные тоже).
Здравствуйте, DrMom, Вы писали:
DM>Здравствуйте, DrMom, Вы писали:
DM>>Здравствуйте, dima_gf, Вы писали:
_>>>Хотя — по поводу стандартности парамкетров я не подумал, впрочем зачем тогда генерировать?
DM>>Незачем. Все и так работать будет. Обычно озаглушке вспоминают тогда когда методы с нестандартными параметрами выпоняться перестают. (сам так все время вспоминаю)
DM>Да уж, нафилиздипил я здесь... Вобщем так. Если все параметры стандартные, то используй атрибут oleautomation и не парься с заглушкой. Если нет, то заглушка нужна. Вот почему сишные файлы не генерятся это для меня загадка, т.к. использование объектов становится возможным только в пределах одного апартамента. Вобще я всегда описывал интерфейсы за приделами библиотеки, т.к. давно сталкивался с этой проблемой. Тогда я выяснил, что если на интерфейс нет ссылок в library XXXLib, то и в библиотеку типов он не попадет.
Вообще то я тоже все описывал за библиотекой и не о чем не думал. Но пришло время наводить порядок в написанных интерфейсах, т.е. одни проекты ссылаются на интерфейсы, определенные в других проектах и пошла чехарда. Идут перекрестные ссылки и все время приходится изголяться, но в результате все равно приходится впихивать файлы xxx_i.x.c — определение IID и CLSID. А хотелось бы обойтись директивой import "...dll" и/или importlib(....dll).
Все это получается, если интерфейсы описывать в библиотеке. Но тогда возникает отсутствие заглушок. А программы у меня таковы, что я работаю в смешаной модели памяти — поэтому без proxy не обойтись. Вот откуда растут ноги этой в общем — то пустяковой заморочке. Обойти можно, но с помощью накруток. Кстати просматривая idl в SDK я так и не понял по какому принципу они их строят — есть файлы полностью в либах (как IWebBrowser), есть частично, а есть вообще по одному коклассу в либе.
Здравствуйте, DrMom, Вы писали:
DM>Здравствуйте, dima_gf, Вы писали:
_>>При создании idl файла, определения интерфейсов можно _>> поместить как в блок библиотеки library:
_>>library DDD _>>{ _>> [...] _>> interface d1 : IUnknown {...}; _>>};
_>>так и перед библиотекой:
_>>[...] _>>interface d1 : IUnknown{...};
_>>library DDD _>>{ _>>};
_>>Если описание поместить в билиотеку, _>>то компилятор НЕ генерит proxy заглушки. Вопрос — почему? И как его _>>заставить генерить их. _>>Может, то что помещено в билиотеку имеет какие-то свои proxy _>>заглушки и не стоит об этом беспокоиться?
DM>А вот я например сделал PS для такого файла:
DM>
DM>// MIDLTest.idl : IDL source for MIDLTest.dll
DM>//
DM>// This file will be processed by the MIDL tool to
DM>// produce the type library (MIDLTest.tlb) and marshalling code.
DM>import "oaidl.idl";
DM>import "ocidl.idl";
DM>[
DM> uuid(D9EC3169-EFAA-42B8-B731-EE244D566D34),
DM> version(1.0),
DM> helpstring("MIDLTest 1.0 Type Library")
DM>]
DM>library MIDLTESTLib
DM>{
DM> importlib("stdole32.tlb");
DM> importlib("stdole2.tlb");
DM> [
DM> object,
DM> uuid(89E8C244-75BE-41F2-BA08-B4D3492533E5),
DM> helpstring("IObj Interface"),
DM> pointer_default(unique)
DM> ]
DM> interface IObj : IUnknown
DM> {
DM> [propget, helpstring("property Func")] HRESULT Func([out, retval] long *pVal);
DM> [propput, helpstring("property Func")] HRESULT Func([in] long newVal);
DM> };
DM> [
DM> uuid(4C7F475E-5D7E-4AFF-B437-D619520EFA4E),
DM> helpstring("Obj Class")
DM> ]
DM> coclass Obj
DM> {
DM> [default] interface IObj;
DM> };
DM>};
DM>
DM>Вобщем я так понимаю, что мой VC6 глючит и от раза к разу если тосовать idl файл то генерит, то нет заглушку. Вот такая вот фигня. Кстати у меня еще ни всегда генерится заглушка в противоположенном варианте! Причем я все время перекомпилю библиотеку заново и удаляю все файлы компилера (сишные тоже).
Глючит не только VC6 но и VC7. Надо делать rebuild заглушки (удалять dll заглушки). А вообще я тоже наблюдал такой эффект если делать простой build — тогда он просто не генерит ничего а впитывает оставшийся файл. Дело в том, что генрация у него проходит в 2 этапа — первый он строит заглушку (сишную) а потом вызывает bat файл который на основании этой заглушки делает dll. Но bat файл тупой и он находит СТАРУЮ сишную заглушку.
Здравствуйте, dima_gf, Вы писали:
DM>>Да уж, нафилиздипил я здесь... Вобщем так. Если все параметры стандартные, то используй атрибут oleautomation и не парься с заглушкой. Если нет, то заглушка нужна. Вот почему сишные файлы не генерятся это для меня загадка, т.к. использование объектов становится возможным только в пределах одного апартамента. Вобще я всегда описывал интерфейсы за приделами библиотеки, т.к. давно сталкивался с этой проблемой. Тогда я выяснил, что если на интерфейс нет ссылок в library XXXLib, то и в библиотеку типов он не попадет.
_>Вообще то я тоже все описывал за библиотекой и не о чем не думал. Но пришло время наводить порядок в написанных интерфейсах, т.е. одни проекты ссылаются на интерфейсы, определенные в других проектах и пошла чехарда. Идут перекрестные ссылки и все время приходится изголяться, но в результате все равно приходится впихивать файлы xxx_i.x.c — определение IID и CLSID. А хотелось бы обойтись директивой import "...dll" и/или importlib(....dll). _>Все это получается, если интерфейсы описывать в библиотеке. Но тогда возникает отсутствие заглушок. А программы у меня таковы, что я работаю в смешаной модели памяти — поэтому без proxy не обойтись. Вот откуда растут ноги этой в общем — то пустяковой заморочке. Обойти можно, но с помощью накруток. Кстати просматривая idl в SDK я так и не понял по какому принципу они их строят — есть файлы полностью в либах (как IWebBrowser), есть частично, а есть вообще по одному коклассу в либе.
Интерфейс можно описать вне библиотеки и при этом, чтобы он вошел в нее. Для этого достаточно чтоб он был добавлен к какому нить коклассу входящему в библиотеку. Я таким методом часто пользовался правда наоборот для сокрытия интерфейса. Просто в idl файле коментарил вхождение интерфейса в кокласс, а сам интерфейс описывал вне библиотеки. Таким образом и прокси компилится и интерфейс не виден в библиотеке, но на запрос QI возвращается. В твоем варианте должна генерится прокся и интерфейс должен входить в библиотеку, т.к. он поддерживается объектом воходящим туда. Попробуй посмотреть через OleViewer. Я думаю если не сработает, то это глюки (у меня это всегда работало) и надо просто потасовать idl.
Здравствуйте, DrMom, Вы писали:
DM>Здравствуйте, dima_gf, Вы писали:
DM>>>Да уж, нафилиздипил я здесь... Вобщем так. Если все параметры стандартные, то используй атрибут oleautomation и не парься с заглушкой. Если нет, то заглушка нужна. Вот почему сишные файлы не генерятся это для меня загадка, т.к. использование объектов становится возможным только в пределах одного апартамента. Вобще я всегда описывал интерфейсы за приделами библиотеки, т.к. давно сталкивался с этой проблемой. Тогда я выяснил, что если на интерфейс нет ссылок в library XXXLib, то и в библиотеку типов он не попадет.
_>>Вообще то я тоже все описывал за библиотекой и не о чем не думал. Но пришло время наводить порядок в написанных интерфейсах, т.е. одни проекты ссылаются на интерфейсы, определенные в других проектах и пошла чехарда. Идут перекрестные ссылки и все время приходится изголяться, но в результате все равно приходится впихивать файлы xxx_i.x.c — определение IID и CLSID. А хотелось бы обойтись директивой import "...dll" и/или importlib(....dll). _>>Все это получается, если интерфейсы описывать в библиотеке. Но тогда возникает отсутствие заглушок. А программы у меня таковы, что я работаю в смешаной модели памяти — поэтому без proxy не обойтись. Вот откуда растут ноги этой в общем — то пустяковой заморочке. Обойти можно, но с помощью накруток. Кстати просматривая idl в SDK я так и не понял по какому принципу они их строят — есть файлы полностью в либах (как IWebBrowser), есть частично, а есть вообще по одному коклассу в либе.
DM>Интерфейс можно описать вне библиотеки и при этом, чтобы он вошел в нее. Для этого достаточно чтоб он был добавлен к какому нить коклассу входящему в библиотеку. Я таким методом часто пользовался правда наоборот для сокрытия интерфейса. Просто в idl файле коментарил вхождение интерфейса в кокласс, а сам интерфейс описывал вне библиотеки. Таким образом и прокси компилится и интерфейс не виден в библиотеке, но на запрос QI возвращается. В твоем варианте должна генерится прокся и интерфейс должен входить в библиотеку, т.к. он поддерживается объектом воходящим туда. Попробуй посмотреть через OleViewer. Я думаю если не сработает, то это глюки (у меня это всегда работало) и надо просто потасовать idl.
Доброе утро.
Это я все знаю. Так оно и происходит. но я то добиваюсь обратного, чтобы он входил только в библиотеку (хотя понимаю, что это в общем то бред) — чтобы в генерируемом хидере он не появлялся — тогда я смогу использовать его тлько через import в stdafx.h. В противном случае, т.к. один и тотже интерфейс входит в разные хидеры разных библиотек, то при использовании их одновременно происходят проблемы переопределений. Конечно можно вообще отказаться от import в stdafx.h файле, и делать import только в idl, тогда необходимые хидеры будут итак вставлены в результирующи файл, что теоретически позволит отказаться от import в stdafx.h.
Здравствуйте, dima_gf, Вы писали:
_>Здравствуйте, DrMom, Вы писали:
DM>>Здравствуйте, dima_gf, Вы писали:
DM>>>>Да уж, нафилиздипил я здесь... Вобщем так. Если все параметры стандартные, то используй атрибут oleautomation и не парься с заглушкой. Если нет, то заглушка нужна. Вот почему сишные файлы не генерятся это для меня загадка, т.к. использование объектов становится возможным только в пределах одного апартамента. Вобще я всегда описывал интерфейсы за приделами библиотеки, т.к. давно сталкивался с этой проблемой. Тогда я выяснил, что если на интерфейс нет ссылок в library XXXLib, то и в библиотеку типов он не попадет.
_>>>Вообще то я тоже все описывал за библиотекой и не о чем не думал. Но пришло время наводить порядок в написанных интерфейсах, т.е. одни проекты ссылаются на интерфейсы, определенные в других проектах и пошла чехарда. Идут перекрестные ссылки и все время приходится изголяться, но в результате все равно приходится впихивать файлы xxx_i.x.c — определение IID и CLSID. А хотелось бы обойтись директивой import "...dll" и/или importlib(....dll). _>>>Все это получается, если интерфейсы описывать в библиотеке. Но тогда возникает отсутствие заглушок. А программы у меня таковы, что я работаю в смешаной модели памяти — поэтому без proxy не обойтись. Вот откуда растут ноги этой в общем — то пустяковой заморочке. Обойти можно, но с помощью накруток. Кстати просматривая idl в SDK я так и не понял по какому принципу они их строят — есть файлы полностью в либах (как IWebBrowser), есть частично, а есть вообще по одному коклассу в либе.
DM>>Интерфейс можно описать вне библиотеки и при этом, чтобы он вошел в нее. Для этого достаточно чтоб он был добавлен к какому нить коклассу входящему в библиотеку. Я таким методом часто пользовался правда наоборот для сокрытия интерфейса. Просто в idl файле коментарил вхождение интерфейса в кокласс, а сам интерфейс описывал вне библиотеки. Таким образом и прокси компилится и интерфейс не виден в библиотеке, но на запрос QI возвращается. В твоем варианте должна генерится прокся и интерфейс должен входить в библиотеку, т.к. он поддерживается объектом воходящим туда. Попробуй посмотреть через OleViewer. Я думаю если не сработает, то это глюки (у меня это всегда работало) и надо просто потасовать idl.
_>Доброе утро. _>Это я все знаю. Так оно и происходит. но я то добиваюсь обратного, чтобы он входил только в библиотеку (хотя понимаю, что это в общем то бред) — чтобы в генерируемом хидере он не появлялся — тогда я смогу использовать его тлько через import в stdafx.h. В противном случае, т.к. один и тотже интерфейс входит в разные хидеры разных библиотек, то при использовании их одновременно происходят проблемы переопределений. Конечно можно вообще отказаться от import в stdafx.h файле, и делать import только в idl, тогда необходимые хидеры будут итак вставлены в результирующи файл, что теоретически позволит отказаться от import в stdafx.h.
Правда в этом случае придется ПРИКОМПИЛИРОВАТЬ файлы xxx_i.c — ЧЕГО я хочу избежать с помощью импортирования библиотеки — откуда компилятор сам может взять все что ему надо. Но видимо ничего не выйдет и придется возвращаться к старому варианту.
_>Правда в этом случае придется ПРИКОМПИЛИРОВАТЬ файлы xxx_i.c — ЧЕГО я хочу избежать с помощью импортирования библиотеки — откуда компилятор сам может взять все что ему надо. Но видимо ничего не выйдет и придется возвращаться к старому варианту.
Здравствуйте, Obukhov, Вы писали:
_>>Правда в этом случае придется ПРИКОМПИЛИРОВАТЬ файлы xxx_i.c — ЧЕГО я хочу избежать с помощью импортирования библиотеки — откуда компилятор сам может взять все что ему надо. Но видимо ничего не выйдет и придется возвращаться к старому варианту.
O>А может попробовать oleautomation использовать ?
А что делать с не oleautomation параметрами. Например передача пользовательского интерфеса IXxx? Как он проксится COM не знает.
Типа даже сишные файлы не создаются? Сейчас попробую.
Вобщем так. Если все параметры стандартные, то используй атрибут oleautomation и не парься с заглушкой. Если нет, то заглушка нужна. Вот почему сишные файлы не генерятся это для меня загадка, т.к. использование объектов становится возможным только в пределах одного апартамента. Вобще я всегда описывал интерфейсы за приделами библиотеки, т.к. давно сталкивался с этой проблемой. Тогда я выяснил, что если на интерфейс нет ссылок в library XXXLib, то и в библиотеку типов он не попадет.
Вот такая вот фигня. Кстати у меня еще ни всегда генерится заглушка в противоположенном варианте! 
Причем я все время перекомпилю библиотеку заново и удаляю все файлы компилера (сишные тоже).
