Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
Форум программистов > C/C++: COM/DCOM/ActiveX/ATL/CORBA > Скрестить Callback и Events в COM объекте |
Автор: ivs4 1.7.2009, 11:32 | ||||||||||
Добрый день. Столкнулся с нетривиальной задачей. Делаю обертку над сторонней библиотекой в виде COM объекта в ATL. В этой библиотеке есть некай ф-ция результат выполнения которой можно узнать через асинхронно через Callback ф-цию. Задача же стоит в вызове метода объекта при наступлении Callback. Сначала подготовил свой объект для вызова ивентов. Делаю первый метод ком объекта без параметров, он отвечает за назначение callback. Сначала хотел сделать CallBack методом класса ком объекта через такой изврат:
При таком раскладе вызов Callback происходит но проблема в вызове метода определенного мною метода события, а конкретно ошибка происходит в этом месте функции события:
те как я понял при таком назначениию callback я не могу корректно обращаться к членам родителя моего класса к таким как IConnectionPointImpl. Хорошо, решил уйти от callback как члена класса и сделал его статическим методом класса. Кроме того ввел в класс статический указатель на самого себя:
вроде все хорошо, callback вызывается но опять проблема с вызовом событийного события Fire_CallBackDone. Выполнение в этом методе ф-ции
Возвращало ошибку -2147221008 (800401F0) Не был произведен вызов CoInitialize. переработал Callback
после этого тот же вызов Invoke выдал ошибку -2147417842 (8001010E) Приложение обратилось к интерфейсу, относящемуся к другому потоку. На сегодняшний момент прихожу к выводу, что невозможно вызвать из callback событие в рамках COM идеология. Думаю уходить от этого решения. Последняя надежда на ваше мнение. Если вдохнете надежду, то буду продолжать. |
Автор: xvr 1.7.2009, 12:47 |
Вызвать можно, но не просто ![]() Для начала мелкое замечание - CoInitialize нужно вызывать в начале каждого потока, где планируется работать с COM объектами. Для вызова объектов между разными потоками (т.е. создан он был в одном, а вызывать его надо в другом) нужно передать сам объект в тот поток, где его планируется вызывать (см CoMarshalInterThreadInterfaceInStream и CoGetInterfaceAndReleaseStream). И еще очень желательно, что бы этот поток крутил цикл обработки очереди сообщений Windows (иначе половина COM инфраструктуры отвалится) |
Автор: ivs4 1.7.2009, 16:26 | ||
Здравствуйте, xvr. Как я думаю, Callback вызывается в своем потоке, не в том, где создается COM объект и соответственно в своем апартменте. Тогда понятно природа ошибок и нужность маршалинга. Но возникают вопросы: Каким образом осуществить маршалинг. Т.е. вы предлагаете в статической переменной вместо того как у меня хранения указателя на класс CMyClass. хранить IStream из которого потом в CallBack доставать указатель на интерфейс CMyClass.
Правильно я Вас понял? |
Автор: xvr 1.7.2009, 23:35 |
В общем так. Вся прелесть в деталях ![]() В том потоке, где был созданн COM объект надо записать его в стрим (с помощью CoMarshalInterThreadInterfaceInStream) и записать полученный стрим в глобал. Затем, в потоке, где надо объект вызывать, делается CoGetInterfaceAndReleaseStream. Полученный объект сохраняется опять же в глобале. Затем все вызовы делаются с этим объектом. Вызывать пару CoInitialize + CoUninitialize на каждый callback не стоит - это довольно дорогая операция Главный вопрос как синхронизировать создание стрима с объектом и его использование, т.к. это должно делаться в разных потоках. Для этого можно воспользоваться сообщениями Windows (т.к. поток-приемник все равно должен крутить цикл обработки сообщений, что бы COM нормально работал). Можно применить и другие методы. Callback'и вызываются в заранее известном потоке, или о их месте вызова ничего неизвестно? |
Автор: jonie 2.7.2009, 07:11 |
можно без сериализации в IStream жить между потоками используя GIT. http://forum.sources.ru/index.php?showtopic=40322 вот примерное объяснение. Это несколько (?) быстрее чем марашалить как делаете вы, но имеет ряд ограничений. |
Автор: ivs4 2.7.2009, 18:21 | ||||||||||||||||
Давайте еще раз обрисуем ситуацию. Вот описание CMyCllass:
обратите внимание на наследование от CProxy_IMyClassEvents. Он отвечает за вызова рукотворных событий. Вот он
Так вот как раз это метод я и вызываю из моего CallBack
1. Как я уже говорил, сначала была проблема с назначением calback в методе SetCallback. Извратился и сделал с помощью typedef и приведения адреса ф-ции к типу long. 2. Потом встала проблема с вызовом из callback метода отвечающего за событие. Это я сделал через статический указатель на сам класс CMyClass. Считаю это не совсем корректным для многопользовательского режима, но там посмотрим. Пока оставил так. 3. Далее спотыкания пошли на Fire_CallbackDone. Не хотелась выполняться строка
Если посмотреть на ф-цию Fire_CallbackDone, то виден цикл, который пробегает по всем членам динамического массива IUnknown интерфейсов m_vec. Там хранятся точки в которых от нас ждут вызова события, например в VBA
По вашему совету, добавил CMyClass укfзатель на IStream. в методе SetCallBack добавил маршпалинг диспатч интерфейса, который используется в Fire_CallbackDone
в сам CallBack добавил
где ptr - глобальный указатель на IDispatch. И уже через него вызываю Invoke
все проходит, hres=0 НО! ивент в бейсике все равно не отрабатывает. В общем я грешу на хранение указателя класса в статической переменной. Иначе в статическом методе до него не добраться. А как ваше мнение? |
Автор: xvr 2.7.2009, 19:20 |
Сработает только один раз. Функция CoGetInterfaceAndReleaseStream извлекает из стрима объект и УНИЧТОЖАЕТ стрим. Т.е. при ее втором вызове (а он будет, т.к. она вставленна в CallBack и значит будет вызываться при каждом его срабатывании) ей уже будет неоткуда извлекать объект. При таком раскладе вариант jonie с GIT выглядит предпочтительней |
Автор: ivs4 4.7.2009, 21:36 | ||
Попробовал маршилинг через GIT - то же самое. Вот эта строка в Fire_CallBackDone
выполняется без ошибок и hres=0, НО ивент из VBA не срабатывает. Подумал про цикл сообщений для доступа к маршалируемому интерфейсу, но где в ATL проекте его прицепить не пойму. |
Автор: xvr 5.7.2009, 00:36 | ||||
Без него работать не будет.
Прицеплять надо там, где VBA создает твой объект. Хотя он там и так есть. Надо обеспечить, что бы он работал, т.е. не мешать ему своими объектами (например создать для их жизнедеятельности отдельную нить) |
Автор: ivs4 5.7.2009, 14:58 | ||
Уважаемый, xvr, Можно об этом чуть по-подробнее. |
Автор: xvr 5.7.2009, 15:12 |
Поподробнее можно. Это означает, что если методы вашего класса вызываются из VBA (да и не только) вы не имеете права запускать внутри них длительную обработку. Вся работа подсистемы COM по доставке сообщений и вызовов будет заморожена, пока вы не вернетесь из вызванного метода обратно в VBA Так же это означает, что если вы создаете свои нити (или кто то создает их от вашего имени - с точки зрения VBA), то в этих нитях должен работать цикл обработки сообщений, если вы собираетесь пользоваться в них инфраструктурой COM |
Автор: ivs4 5.7.2009, 17:47 |
Т.е. в потоке сторонней библиотеки к которой принадлежит CallBack я должен сделать цикл? Но этот поток мне доступен только когда библиотека библиотека активирует CallBack. Т.е. в этом CallBack я должен сделать цикл? А он должен быть до или после вызова Fire_CallBackDone? Добавлено через 8 минут и 59 секунд И еще вопрос. Вечный цикл не поставишь, тогда на какое сообщение надо выходить? |
Автор: xvr 5.7.2009, 22:09 |
Цикл должен крутится со стороны VBS, там где клиенты подсоединяются к вашему CProxy_IMyClassEvents (кстати, у вас маршалинг CProxy_IMyClassEvents расчитан только на 1 подсоединение) Кроме того, event может вообще не сработать, т.к. вы маршалите к себе чужой интерфейс, а он может быть на это не рассчитан Я бы вообще отказался от прямого вызова Fire_CallbackDone из CMyClass::Callback, а сделал бы вызов через передачу Виндового оконного сообщения |
Автор: ivs4 6.7.2009, 08:25 | ||
Спасибо за ответы, xvr. Вы писали
Попробую расписать ваше предложение. Вы говорите о передаче оконного сообщения. Хорошо, я регистрирую новое сообщение. Затем в конструкторе класса CProxy_IMyClassEvents запускаю некий новый поток с циклом приема оконных сообщений и в случае получения им моего сообщения вызываю Fire_CallbackDone. В самом Fire_CallbackDone производить демаршалинг интерфейсов и вызывать через них ивенты в VBA. 1. Правильно ли я развернул Вашу мысль? 2. Какому HWND посылать мое сообщение о вызове CallBack? |
Автор: ivs4 6.7.2009, 13:56 |
Может быть сделать не ожидание сообщения, а ожидания виндового события с таймером, а между тиками проверки события обрабатывать сообщения? |
Автор: xvr 6.7.2009, 15:54 |
Вам нужно в каждом thread'е, в котором вызывается Advise из вашего IConnectionPointContainer'а создавать невидимое окно с оконной функцией, которая в ответ на некоторое сообщение (например WM_USER) будет вызывать FireEvent. Handle'ы на все созданные окна нужно сложить в массив и рассылать по ним этот самый WN_USER на каждый callback. При shutdown'е всей этой бодяги надо не забыть разрушить все окна. |
Автор: ivs4 7.7.2009, 08:56 |
Как я понимаю, Advise вызывается клиентской стороной для передачи своего интерфейса, через который в свою очередь вызывается ивент. Вот, что я подумал. Что если в ф-ции SetCallBack производить следующтие действия. Создать новый поток, передать в этот поток указатель на CMyClass, в потоке работает цикл сообщений, при срабатывании CallBack посылаем в порожденный поток сообщение и в этом потоке вызывается Fire_CallbackDone. В данной схеме возможно еще понадобиться маршалинг. А вообще как можно отследить когда вызван advise, чтобы тогда создать этот поток не в SetCallBack а там. |
Автор: xvr 7.7.2009, 09:19 |
Вызывается Advise клиентской стороной но из вашего объекта (это метод интерфейса IConnectionPointContainer, который имплементирован в вашем классе) Создание отдельного потока в CallBack у себя не поможет - при этом придется маршалить к себе в поток VBA'ный объект - приемник событий, а именно он после именно такого маршалинга и не работал ![]() И вообще, все методы всех интерфейсов вашего объекта будут вызываться в одном потоке (это обеспечивает COM, если вы конечно не поставили у вашего класса Neutral Threaded модель) Из этого же потока должны вызываться все event'ы (FireEvent). В этом же потоке VBS будет САМ крутить цикл обработки сообщений |
Автор: ivs4 7.7.2009, 09:37 |
Тогда не понятно куда ставить цикл сообщений, если его надо ставить в поток где вызываются все методы интерфейсов. В методы его не поставишь. Где вызывается Advise, честно говоря, я не вижу. Добавлено через 6 минут и 22 секунды Или же все тщетно - не вызвать из Callback событие? |
Автор: xvr 7.7.2009, 12:09 | ||||||||
Никуда его не надо ставить - он уже есть в VBA
Как то так:
![]() |
Автор: ivs4 10.7.2009, 17:28 | ||||
Попробовал вызов события через передачу сообщения в ф-цию окна. Теперь работает все без маршалинга и hres=0, но все равно, к сожалени ИВЕНТ не вызывется. Может что не то сделал?
|
Автор: xvr 10.7.2009, 22:52 |
Вроде все правильно (не считая того, что класс окна нужно регистрировать только 1 раз). А obj->Fire_CallBackDone вызывается? Может какие то несостыковки в Appartament моделях объекта и приложения? |
Автор: ivs4 11.7.2009, 23:39 | ||
Попробовал еще вот этот вариант: http://support.microsoft.com/kb/196026/ все равно не вызывается событие. В Fire_CallBackDone
возвращает 0, но без события. Может что-то не то с этой библиотекой откуда вызывается CallBack? Хотя не должно. Сообщение доходит до обработчика и файр вызывается. |
Автор: ivs4 12.7.2009, 17:48 | ||
Удалось заставить заработать событие в VBA. Для этого в VBA в то место где ожидается срабатывание события добавил следующую ф-ция засыпания на 1 секунду.
Скорее всего сообщение ассоциированное с Invoke не обрабатвается. Конечно нет желания ставить такую обработку в клиентском коде. Как бы это обойти? |
Автор: xvr 12.7.2009, 19:12 |
А как VBA'ная прога ждет события? Если она в это время что то считает, то событие не будет принято - события принимаются только в Idle состоянии. Можно заставить их принимать и не в Idle, но тогда надо явно крутить цикл обработки событий, что SleepVB и делает (в DoEvents) |
Автор: ivs4 13.7.2009, 21:47 |
А другого варианта как цикл DoEvents в VBA нет? Я знаю, что майкрософтовский winsock сервер работает не так. Там событие прихода вызывается асинхронно. |
Автор: xvr 14.7.2009, 09:16 | ||||
Есть. Написать нормальный обработчик в VBA. Точнее - обеспечить что бы VBA приложение работало так, как рассчитана модель событий VBA. Все события в VBA сериализуются, т.е. пока не закончится обработка одного, обработка другого не начнется (если не звать принудительно DoEvents)
![]() |
Автор: ivs4 16.7.2009, 07:55 |
Спасибо за ответы. Полагаю тема исчерпана. |