Здравствуйте, Аноним, Вы писали:

А>Оч. просто: длл не должна трогать CoInitialize/CoUninitialize — это дело екзешника.

Это дело самого .exe, если COM явно используется — то вызывать, если нет — то не вызывать. Используется COM где-то в дебрях dll или нет — это не его забота.

А>Обратите на этот факт внимание — не делайте CoInitialize/CoUninitialize в длл.

Почему, коран запрещает? Если есть вероятность, что COM может быть не проинициализована для потока, то нужно вызывать. Можно делать несколько вызовов CoInitialize/CoUninitialize в потоке, главное чтобы они были парными. DLL — это отдельная, независимая часть кода. Она может использоваться с разными приложениями и в общем случае никто не обязан инициализировать для нее COM.

Здравствуйте, Аноним, Вы писали:

А>Именно. И много ДЛЛ. Если каждая из них будет сама звать CoInitialize и CoUninitialize — запросто выростут бородавки. Положим, мой екзе загрузил такую длл и она втихаря сделала CoInitialize, я об этом не подозреваю. Мне в екзешнике понадобился СОМ, в пределах одной функции. Я зову CoInitialize, не проверяю что вернула
А>А если человек всё же возвращаемое значение проверяет — я лично никогда не видел попыток с ним разбираться: если CoInitialize FAILED (или даже != S_OK) — завершаем программу (как правило) или же отменяем действие. Можно конечно сказать, что все эти люди глупы и криворуки, потом как не понимают что я мог CoInitialize/CoInitialize из длл вызывать. Но, имхо, это определение сорее применимо к автору длл.

Если DLL внутри функции вызовет CoInitialize и затем корректно за собой почистит при выходе из функции, то на EXE это никак не отразится. Я говорю именно о таком сценарии.

А>На протяжении многих лет этот вопрос (и вызванные "нарушением конвенции" проблемы) всплывает в форумах и вы первый из виденных мной, кто стал оспаривать очевидное. ИМХО, у вас просто просто есть такой код, зовущий CoInitialize/CoUninitialize из длл, он работает (у вас лично) и сознаться в неправильности подхода вы не хотите в первую очередь себе.
А>Не уверен, но вроде когда-то в МСДН была настоятельная рекомендация так не делать и в любом случае так не делать — сложившаяся практика. Когда я лично ишу екзе — у меня и в мыслях нет, что СОМ ещё кто-то дергает, а если кто будет на этом пойман — выброшу такие зависимости.

Я не агитирую инициализировать COM только в DLL, я отвечаю на фразу "Обратите на этот факт внимание — не делайте CoInitialize/CoUninitialize в длл". Понятно, что когда вы полностью котролируете разработку как EXE так и используемых DLL, то проще всего делать инициализацию один раз и вообще забыть об этой проблеме. Однако жизнь — сложная штука, возможны самые разные ситуации. Например вы добавляете функционал к чужой EXE, и заказчик хочет только добавить к ней вызов одной функции из DLL и настоятельно не хочет ничего больше трогать и добавлять всякие CoInitialize. Это большое сложное приложение, разработчиков уже не осталось и он не хочет ничем рисковать. Или вы предлагаете готовую библиотеку для сторонних приложений. Можно конечно написать большими буквами в описании про необходимость инициализации COM, но половина все равно этого не прочитает. А можно просто позаботиться о том, чтобы DLL работала в любом окружении. Насколько я знаю, "Не инициализируй COM из DLL" в десяти заповедях не присутствует.

У меня есть обычная win32 dll.
В ней все на Win32 API написано.

Хочу из нее обращаться к ActiveX контролу,
зарегистрированному в системе.

Как это сделать используя только Win API?

С уважением,
Вован.

Так ActiveX или просто COM объект?
Если просто COM — включаете соотств хедеры или пользуете #import directive, зовёте CoCreateInstance — и вперёд. События — читайте про IDispatch, IConnectionPoint, IConnectionPointContainer, альтернатива — использование ATL или MFC. Если ActiveX — надо делать свой контейнер для него — не стоит возиться, брать ATL или MFC, получив заодно поддержку СОМ событий.

Здравствуйте, Аноним, Вы писали:

А>Так ActiveX или просто COM объект?
А>Если просто COM — включаете соотств хедеры или пользуете #import directive, зовёте CoCreateInstance — и вперёд. События — читайте про IDispatch, IConnectionPoint, IConnectionPointContainer, альтернатива — использование ATL или MFC. Если ActiveX — надо делать свой контейнер для него — не стоит возиться, брать ATL или MFC, получив заодно поддержку СОМ событий.

Я создал MFC-вое приложение (dialog based), кинул на него ActiveX контрол, и у меня получилось подергать этот контрол успешно.

Но когда попытался в MFC DLL запустить немодальное окошко, на котором у меня также ActiveX контрол — то ничего не получилось

Есть там какие-то хитрости с этим?

Здравствуйте, <Аноним>, Вы писали:

А>Хочу из нее обращаться к ActiveX контролу,
А>зарегистрированному в системе.
А>Как это сделать используя только Win API?

Рекомендую серию статей "COM in plai C" от Jeff Glatt.

__V>Но когда попытался в MFC DLL запустить немодальное окошко, на котором у меня также ActiveX контрол — то ничего не получилось
__V>Есть там какие-то хитрости с этим?
В принципе нет. А процесс использующий DLL СОМ инициализирует (CoInitialize[Ex])?

Здравствуйте, Аноним, Вы писали:

__V>>Но когда попытался в MFC DLL запустить немодальное окошко, на котором у меня также ActiveX контрол — то ничего не получилось
__V>>Есть там какие-то хитрости с этим?
А>В принципе нет. А процесс использующий DLL СОМ инициализирует (CoInitialize[Ex])?

...не инициализировал.. проинициализировал — все зашуршало!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
супер! спасибо огромное..
странно, что МФЦ позволяет так быстро контрол вставить на диалог и переменную для него создать, а чтоб заработало инициализацию не вставляет.. хотя наверно я чет недопонял просто

Еще раз спасибо!

С уважением,
Вован.

Здравствуйте, Аноним, Вы писали:
Оч. просто: длл не должна трогать CoInitialize/CoUninitialize — это дело екзешника. Обратите на этот факт внимание — не делайте CoInitialize/CoUninitialize в длл.

algol wrote:
> А>Обратите на этот факт внимание — не делайте
> CoInitialize/CoUninitialize в длл.
> Почему, коран запрещает?
Именно.

> Если есть вероятность, что COM может быть не
> проинициализована для потока, то нужно вызывать.
В потоке уже мог быть установлен MTA, тогда CoInitialize вернет ошибку.

А если CoInitialize делается для THREAD_ATTACH, то вообще можно получить
баальшую багу, если потом приложение захочет поставить MTA в этот поток.

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

>> Почему, коран запрещает?
C>Именно.

Ссылку на коран в студию.

C>В потоке уже мог быть установлен MTA, тогда CoInitialize вернет ошибку.

Замечательно, мы узнали, что COM проинициализирована, CoUninitialize вызывать не нужно.

C>А если CoInitialize делается для THREAD_ATTACH, то вообще можно получить
C>баальшую багу, если потом приложение захочет поставить MTA в этот поток.

А вот в DllMain вызывать CoInitialize не рекомендуется:

Because there is no way to control the order in which in-process servers are loaded or unloaded, it is not safe to call CoInitialize, CoInitializeEx, or CoUninitialize from the DllMain function.

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

>>Почему, коран запрещает?
Мой — да.

>>Если есть вероятность, что COM может быть не проинициализована для потока, то нужно вызывать.
Нужно задокументировать, что СОМ должен быть инициалилизирован.

>>Можно делать несколько вызовов CoInitialize/CoUninitialize в потоке, главное чтобы они были парными.
>>DLL — ... Она может использоваться с разными приложениями
>>Именно. И много ДЛЛ. Если каждая из них будет сама звать CoInitialize и CoUninitialize — запросто выростут бородавки. Положим, мой екзе загрузил такую длл и она втихаря сделала CoInitialize, я об этом не подозреваю. Мне в екзешнике понадобился СОМ, в пределах одной функции. Я зову CoInitialize, не проверяю что вернула, а потом — зову CoUninitialize. И моя программа пользующая вашу длл горит синим огнём, падая, скажем, через пять минут после этого и, допустим, не каждый раз, а в 5% случаев. Не самый приятный баг и чересчур жестокое наказание за непроверку значения возврщаемого CoInitialize, isn't it? Могу ещё кучу реалистичных ситуаций придумать.

>>в общем случае никто не обязан инициализировать для нее COM.
Неверно — см, например, майкрософтский подход

Имхо, ни один (нормальный) програмер не ожидает, что длл дергает CoInitialize/CoUninitialize и ни один (нормальный) этого в длл не делает. Конвенция.

>>>Можно делать несколько вызовов CoInitialize/CoUninitialize в потоке, главное чтобы они были парными.
>>>DLL — ... Она может использоваться с разными приложениями
Именно. И много ДЛЛ. Если каждая из них будет сама звать CoInitialize и CoUninitialize — запросто выростут бородавки. Положим, мой екзе загрузил такую длл и она втихаря сделала CoInitialize, я об этом не подозреваю. Мне в екзешнике понадобился СОМ, в пределах одной функции. Я зову CoInitialize, не проверяю что вернула
А если человек всё же возвращаемое значение проверяет — я лично никогда не видел попыток с ним разбираться: если CoInitialize FAILED (или даже != S_OK) — завершаем программу (как правило) или же отменяем действие. Можно конечно сказать, что все эти люди глупы и криворуки, потом как не понимают что я мог CoInitialize/CoInitialize из длл вызывать. Но, имхо, это определение сорее применимо к автору длл.
На протяжении многих лет этот вопрос (и вызванные "нарушением конвенции" проблемы) всплывает в форумах и вы первый из виденных мной, кто стал оспаривать очевидное. ИМХО, у вас просто просто есть такой код, зовущий CoInitialize/CoUninitialize из длл, он работает (у вас лично) и сознаться в неправильности подхода вы не хотите в первую очередь себе.
Не уверен, но вроде когда-то в МСДН была настоятельная рекомендация так не делать и в любом случае так не делать — сложившаяся практика. Когда я лично ишу екзе — у меня и в мыслях нет, что СОМ ещё кто-то дергает, а если кто будет на этом пойман — выброшу такие зависимости.

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

>>DLL работала в любом окружении. Насколько я знаю, "Не инициализируй COM из DLL" в десяти заповедях не присутствует.
В принципе да. Посему разводить из-за этого большую дискуссию нет большого смысла. Я, главным образом, хотел привлечь внимание новичка к факту наличия скользкого места, не утруждая себя подробностями (русской клавиатуры нет, вслепую по-русски не умею, onscreen keyboard — то ещё удовольствие). Если он ветку читает — то, думаю, не поскользнётся. А как конкретно не поскользнётся — личное дело.

Доброго времени суток,

Уважаемые, а не можете подсказать такую вещь, опишу задачу:
1. Есть ActiveX Control не визуальный !!!, но поддерживает event sinks.
2. Есть приложение на Java(не пугаться, это по теме).
3. Написал классик на Java, вызов dll идет из одного потока(не основного), CoInitialize/CoUnitialize в одном потоке(Вызов из Java кода на C++ не суть проблемы, можно считать есть обычные dll функции).
4. Надо создать на WinAPI ActiveX и подписатся на события, причем ест-но желательно они приходили

Пробовал создать модальный диалог с помощью визардов, пробовал руками host создать, объект живет, методы вызываются,
а вот события НЕ ПРИХОДЯТ никак, в чем дело не пойму.
В ActiveX события возникают 100%, видно по Debug Output, но я их не получаю.

Буду очень благодарен на дальнейшие направления куда смотреть.

Спасибо за уделенное время.

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

D>1. Есть ActiveX Control не визуальный !!!, но поддерживает event sinks.

Если это не контрол, а обычный COM сервер, то не требуется ни диалог, ни host window, а достаточно директивы #import

Автор(ы): Игорь Ткачёв
Дата: 9.03.2001

В данной статье приводится объяснение работы директивы #import
компилятора Visual C++ и даны примеры её использования с
MS Word, MS Excel, ADO DB и ActiveX Control.

и _com_ptr_t::CreateInstance().

D>4. Надо создать на WinAPI ActiveX и подписатся на события, причем ест-но желательно они приходили

Например здесь

Автор(ы): Владислав Чистяков

.

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

Спасибо, большое.

Сейчас смотрю....

В есть еще визульный ActiveX Control, а с ним как ???

Спасибо за уделенное время.