ПРОГРАММИРОВАНИЕ НА VISUAL C++

Выпуск No. 49 от 8 июля 2001 г.

Добрый день, дорогие подписчики!

/ / / / СТАТЬЯ / / / / / / / / / / / / / / / / / / / / / /

Добавление технологии Connection point в приложение на базе библиотеки MFC

Часть 1. Необходимость существования и принцип работы Connection point

В данной статье я сделал попытку объяснить, что такое Connection point, её (его - кому как нравится) устройство и принцип работы. Плохо или хорошо у меня это получилось, судить вам.

Структура статьи построена таким образом, чтобы человек, НИЧЕГО не знающий об этой аббревиатуре, не только понял общие принципы работы, но и смог реализовать данную возможность в своих программах с использованием MFC технологии. Я сам в свое время реально столкнулся с проблемой в максимально сжатые сроки изучить и реализовать этого "зверя", ни разу и не слышав о нем раньше. Если вы находитесь в подобной ситуации, то эта статья для вас.

Я не претендую на академическую точность изложения материала, потому как тот кусочек текста, что вы будете читать, есть не детальный перевод материала из MSDN, а моя попытка систематизировать те знания, которыми я обладаю и преподнести их вам в том контексте и порядке, который, как я считаю, сильно помог бы мне в свое время. Считаю нужным заметить, что реализация Connection point на MFC и ATL сильно отличаются, впрочем, равно как и реализация самих СОМ-серверов. Именно ввиду этого я и выбрал в качестве примеров библиотеку MFC. Дело в том, что про использование Connection point на ATL написано немало статей - я в этом лично убедился. Да и, кроме того, сам мастер в ATL без проблем позволяет добавить и использовать эту технологию. Что же касается MFC, то здесь это сопряжено с некоторыми трудностями. Поэтому, думаю, что те люди, у которых будет необходимость работать именно с MFC, хоть немного, но получат пользу от этого материала. Я постараюсь детально рассказать о тех подводных камнях, с которыми вы можете столкнуться при этом, и помогу вам преодолеть их. Остается добавить, что я буду искренне благодарен любым поправкам и советам в мой адрес.

Итак, начнем! Для начала неплохо бы открыть MSDN и посмотреть словарик на этот счет - Glossary (Platform SDK: COM). Мы можем увидеть следующую вещь:

Connection point object (объект точки связи)
Это СОМ-объект, который управляется Connectable object и содержит реализацию IConnectionPoint интерфейса. Одна или более точек соединения объектов может быть создана и управляться Connectable object. Каждая точка соединения объекта управляет поступлением событий от специфического интерфейса к другому объекту и пересылкой этих событий к клиенту.

Теперь смотрим, что такое Connectable object:

Connectable object (соединяемый объект)
Это СОМ-объект, который реализует, как минимум, интерфейс IConnectionPointContainer для управления точкой соединения объектов. Соединяемые объекты поддерживают связь от сервера к клиенту. Соединяемый объект может создавать и управлять одной или более точками соединения подобъектов, которые получают события от интерфейсов реализованных в других объектах и посылают их клиентской стороне.

Ну как, все понятно? Мне не очень… - тогда читаем дальше.

Давайте вспомним знаменитый CALLBACK способ общения интерфейса API программ на языке C. Предположим, что у вас есть некая DLL, которая содержит в себе экспортируемую функцию, предназначенную для архивирования документов. Пусть у неё имеется два параметра. Первый - это путь к папке с документами, которую следует заархивировать, а второй… ну второй - это указатель на функцию. Callback-функцию - функцию обратного вызова.

FolderArchiving( LPCSTR lpszFolderPath, LOGCALLBACKFUNC *pfnLogCallbackFunc)

Где формат функции обратного вызова следующий:

typedef BOOL (LOGCALLBACKFUNC)(LPCSTR lpszDocPath, int nCurrenDoc);

Т.е. в эту функцию будет передаваться номер архивируемого документа и путь к нему.

Как же это все работает? Клиент определяет в своем приложении функцию с любым именем, строго имеющую те же параметры, что описаны выше - речь идет о функции обратного вызова, - а затем передает указатель на неё в FolderArchiving. После чего DLL начинает свою работу по архивированию сообщений и периодически, перед началом упаковки каждого документа будет вызывать ту функцию, адрес которой передал ей клиент, указывая в её параметрах номер документа и путь к нему. Таким образом, клиентское приложение получает весьма симпатичный механизм наблюдения за процессом архивирования. И при желании может вести log-файл, а также отображать диалог прогресса, если таковой не реализован в DLL. Вот, собственно, что такое CALLBACK, если объяснить на пальцах в двух словах. На рисунке 1 вы видите небольшую диаграмму, схематически поясняющую процесс работы, описанный выше.

Подобный механизм "обмена" повсеместно распространен среди функций API операционной системы. Его же часто используют разработчики в своих модулях, как в приведенном выше примере.

Теперь представим ситуацию, что та DLL, о которой шла речь, получила кроме API-интерфейса ещё и СОМ-интерфейс. А в вашу задачу входит реализация всех API-функций в виде СОМ-функций. И что же мы будем делать с нашим Callback? Вот тут на помощь и придет технология Connection point! Это фактически тот же механизм обратного вызова, только приспособленный для СОМ модели, естественно со своими правилами и отличиями.

Модель COM не всегда имела возможность взаимодействия с помощью исходящих интерфейсов. Было время, когда она воспринималась исключительно как модель входящих интерфейсов. В этой связи, чтобы подчеркнуть важность существования Connection points, давайте смоделируем следующую ситуацию.

Пусть у нас имеется приложение PostAgent с СОМ-интерфейсом. Пусть оно будет ЕХЕ-сервером и может работать как самостоятельное приложение с графическим интерфейсом. В число достоинств этой программы входит работа с архивами почтовых программ. Некоторые особенности работы с почтовыми архивами оказались настолько важны, что разработчики PostAgent вынесли их в отдельные СОМ функции в каком-либо интерфейсе. Замечательно! Теперь вы сможете пользоваться услугами этого приложения, и ваша программа получит тот функционал, которого, возможно, вам так не хватало все это время.

Путь среди функций этого СОМ сервера имеется функция MessageArchiving, которая архивирует почтовые сообщения программы Outlook фирмы Майкрософт. Архивы могут быть настолько огромными, что этот процесс подвесит ваше клиентское приложение на несколько часов (без какой-либо возможности взаимодействия с пользователем), пока функция архивирования наконец не выполнится полностью СОМ-сервером. Как можно бороться с этим? Первое, что приходит на ум, - это создание отдельного потока, в котором и вызовется эта "долгая" функция. Но не все тут так просто… Давайте вспомним, что для того, чтобы использовать модель СОМ в вашем приложении, вы должны проинициализировать её с помощью функции CoInitialize или CoInitializeEx. Думаю, первая функция нам не подходит, т. к. наверняка вы будете использовать не только MessageArchiving, но и другие методы. Если учесть, что специально для неё (MessageArchiving) мы создали отдельный поток, то логично предположить, что работа с остальными функциями сервера PostAgent будет осуществляться, как минимум, ещё из основного потока. Поэтому, чтобы из всех потоков можно было работать с одним и тем же СОМ-сервером, нам необходима многопоточная инициализация модели СОМ (MTA), с помощью CoInitializeEx. Доказал? Будем надеяться, что да.

Что дальше? У нас все работает - потоки отлично исполняются, сообщения архивируются, даже налажен четкий механизм критических секций в коде… Но вот ваш шеф сказал вам, что ваше приложение ДОЛЖНО поддерживать механизм OLE-drag-drop. Вы сталкивались с этим? Нет? Значит, ваше счастье. Почему я так говорю? А потому, что для того, чтобы работать с drag-drop, нужно инициализировать однопоточную модель СОМ (STA), и все тут! Дело в том, что пока нет известного мне механизма OLE-drag-drop, реализованного через MTA. Когда разрабатывалась и создавалась технология ОЛЕ, в ней вообще не было понятия MTA.

Ну и что теперь будем делать дальше? Можно попытаться объяснить шефу, что это "невозможно". Но если он не поймет этого? Тогда придется инициализировать СОМ для каждого потока отдельно, в каждом из них вызывать СОМ-сервер, вводить глобальные переменные для того, чтобы обмениваться информацией между разными функциями одного и того же СОМ-сервера. А можно инициализировать STA один раз, но при этом применять процедуры маршалинга и самому следить за синхронизацией потоков и вызовами СОМ. В общем, кошмар. Допускаю, что это несколько утрированный пример, и, возможно, его можно как-то решить способами, которых я не знаю. Однако я сомневаюсь, что эти решения дадутся без боли в голове и будут претендовать на изящность. Ну а если, ко всему прочему, я добавлю ещё и неаккуратность самих разработчиков сервера PostAgent, то вполне может произойти ситуация, когда PostAgent просто повиснет, зациклится… да что угодно, но управления вам так и не вернет. Почему вы должны страдать от этого?

Вполне логично спросить, наконец, чего ради я начал тут столь бурные излияния на искусственно придуманный пример, и какое отношение ко всему этому имеет Connection point. А вот давайте все же немного дофантазируем, раз уж вы смогли дочитать этот текст до настоящего момента и понять, о чем идет речь.

А если с самого начала разработчики PostAgent подошли бы немного с другой точки зрения к реализации своих интерфейсов? Что я имею ввиду? А вот что. Все вызовы СОМ являются по своей природе синхронными вызовами. Это означает, что СОМ-сервер не отдаст вам управление до тех пор, пока не выполнится функция, которую вы вызвали. Но с появлением Connection point получила право на жизнь и асинхронная модель функций в СОМ. То есть "солидные" приложения и их разработчики (не в пример разработчикам PostAgent) реализуют в своих серверах 2 интерфейса для одного и того же набора функций. Один из них является синхронным, а другой - асинхронным. Про некоторые прелести синхронных функций я вам только что рассказал. А как работают асинхронные функции?

Примерно так. Вы вызываете асинхронную функцию, реализация которой заключается в том, чтобы сохранить переданные ей параметры в некой глобальной структуре данных, затем запустить внутри СОМ-сервера поток, который будет выполнять действия по обработке переданных данных и вернуть управление клиенту. Вот и все! И никакой головной боли, что я описывал выше. Вы вызвали MessageArchiving, она запомнила переданные вами данные, вернула вам управление, а сама заставила PostAgent выполнять задачу в фоновом для вас режиме. Однако если идти дальше, то вам может понадобиться и механизм, с помощью которого вы смогли бы не только наблюдать за тем, что делает сейчас работающий СОМ-сервер, но так же и знать когда он закончит свою работу. Ведь так?! Понимаете, куда я клоню? Правильно! Сигнализировать о том, что работа функции, наконец, закончена, может специально предназначенный для этого Connection point. Кроме того, с его же помощью можно и прервать работу функции, если сделать соответствующий функционал в сервере. Но об этом позже. Таким образом, умелое сочетание синхронных и асинхронных функций даст возможность реализовать максимально эффективное взаимодействие через СОМ.

Думаю к настоящему моменту уже должно быть понятно, зачем нужны Connection points , а также хотя бы примерно, что это такое. Теперь перейдем к более детальному рассмотрению.

Connection point подразумевает под собой соединение. Соединение состоит из 2 частей: из объекта, вызывающего интерфейс и называемого источником, и из объекта, содержащего реализацию этого интерфейса и называемого приемником. Устанавливая точку соединения, источник позволяет приемнику присоединиться к себе. С помощью механизма точки соединения (интерфейс IConnectionPoint) указатель на интерфейс приемника передается объекту источника. Этот указатель обеспечивает источнику доступ к функциям-членам реализации приемника. К примеру, для возбуждения события, реализованного приемником, источник может вызвать соответствующий метод из реализации приемника.

Часть 2. Создание СОМ-сервера

Программа-пример Server

Итак, давайте создадим внутризадачный СОМ-сервер (DLL), который будет предоставлять клиенту одну-единственную функцию, результатом работы которой будет возбуждение события. Для этого запустите Visual Studio и выберите меню File->New. Затем в появившемся диалоге выберите вкладку Projects и в поле имени проекта введите ту информацию, что указана на рисунке 2, а также в качестве используемого мастера выберите MFC AppWizard (dll).

Нажмите ОК и вы увидите следующий диалог (рисунок 3). Поставьте установки, как показано на рисунке, и не забудьте отметить птичкой опцию Automation. Это важно, т.к. лишь в этом случае мастер добавит к нашему проекту код, необходимый для СОМ-сервера.

Нажмите Finish. Если вы сделали все правильно, то в окне ClassView вы должны увидеть ту же картину, что и на рисунке 4.

Итак, что же нам создал мастер? Он добавил минимальный джентльменский набор, который обеспечит существование скромному внутризадачному (DLL) СОМ-серверу. Это функции DllCanUnloadNow, DllGetClassObject и DllRegisterServer. Среди этих функций также должна находиться функция DllUnregisterServer, которая, на мой взгляд, также важна, как и DllRegisterServer, однако разработчики в Майкрософт почему-то так не считают. О том, как добавить в СОМ-сервер механизм unregistered, я расскажу в другой статье. Кроме того, в функцию InitInstance мастер добавил следующий код регистрации фабрики классов, за что ему и спасибо.

BOOL CPointServerApp::InitInstance()
{
   // Register all OLE server (factories) as running.  This enables the
// OLE libraries to create objects from other applications.
   COleObjectFactory::RegisterAll();

   return TRUE;
}

Пожалуй, все? Нет, не все. Если вы посмотрите в файлы проекта, созданные мастером, то увидите среди них замечательный файл описания интерфейсов PointServer.odl, содержимое которого имеет вид:

// PointServer.odl : type library source for PointServer.dll
// This file will be processed by the MIDL compiler to produce the
// type library (PointServer.tlb).

[ uuid(D46238B8-2277-11D5-964D-00001CDC1022), version(1.0) ]
library PointServer
{
   importlib("stdole32.tlb");
   importlib("stdole2.tlb");

   //{{AFX_APPEND_ODL}}
//}}AFX_APPEND_ODL}}
};

Что же, так и должно быть - это заготовка библиотеки, в которую мы потом добавим необходимый код. Кстати, учтите, что uuid-идентификаторы у вас будут отличаться, так как это все же уникальное число, поэтому не забывайте далее по коду вставлять свои значения.

Теперь добавим в наш сервер интерфейс, который будет содержать в себе один метод. Для этого выберите View->ClassWizard. В появившемся диалоге выберите вкладку Automation и нажмите Add Class->New. Появится диалог, изображенный на рисунке 5. Введите в необходимые поля информацию, указанную на рисунке.

Таким образом, мы указываем мастеру, что хотим добавить в наш сервер объект, обработка событий которого будет происходить в классе CMyInterface, и что ProgId нашего интерфейса будет иметь имя «PointServer.MyInterface» (его потом можно будет использовать для идентификации интерфейса при его вызове, например, в БЕЙСИКе - это очень удобно).

Кроме того, обратите внимание на одну важную особенность! Наш класс является производным от класса CCmdTarget - это необходимо. Дело в том, что библиотека MFC реализует модель Connection point в классах CConnectionPoint и CCmdTarget. Классы, наследуемые от CСonnectionPoint, реализуют IConnectionPoint интерфейс, используемый для предоставления точек соединения другим объектам, а классы, наследуемые от CСmdTarget, реализуют IConnectionPointContainer интерфейс, который может перечислять все доступные точки соединения объекта или искать специфическую точку соединения. Вернитесь к началу статьи и прочитайте ещё раз определения терминов Connectable object и Connection point object.

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

Ну, вот теперь жмите ОК.

Теперь в диалоге MFC ClassWizard, который, я надеюсь, вы ещё не закрыли, вам стала доступна кнопка Add Method. Жмите её и заполняйте предложенную вам форму данными, указанными на рисунке 6.

Здесь мы указываем мастеру, что нам необходимо определить в нашем интерфейсе функцию FireMyEvent без параметров. Эту функцию мы будем использовать с единственной целью - чтобы сгенерировать событие, которое вызовет исходящую функцию - собственно наш Connection point. Жмите ОК в этом диалоге, а затем и в диалоге MFC ClassWizard.

Смотрим, что получилось. На рисунке 7 видно, что в наш проект добавились новые классы.

Это класс CMyInterface и интерфейс IMyInterface. Я не буду подробно описывать те вещи, которые добавил мастер в ODL файл, а также в файл реализации класса CMyInterface, так как это предмет другого разговора. А мы сейчас пытаемся добавить поддержку точек соединения, и я предполагаю, что с подобными вещами вы уже знакомы.

Теперь нам нужно сгенерировать уникальный GUID. Он будет однозначно идентифицировать интерфейс, который мы собираемся описать в ODL-файле, и который будет содержать исходящий метод, что мы будем вызывать на клиентской стороне. Я для этого пользуюсь замечательной утилитой Guidgen.exe, которая поставляется вместе со студией. Итак, откройте ODL файл нашего проекта и сразу после директив импорта двух TLB-фалов, что любезно добавил туда мастер, вставьте следующее объявление интерфейса, не забывая при этом менять значения уникального идентификатора на свое значение.

importlib("stdole32.tlb");
importlib("stdole2.tlb");

[ uuid(F7222740-2296-11d5-964D-00001CDC1022) ]
dispinterface IFireClassEvents
{
   properties:
   methods:
      [id()] boolean MyEvent();
}//  Primary dispatch interface for CMyInterface

[ uuid(D46238C5-2277-11D5-964D-00001CDC1022) ]
dispinterface IMyInterface
{
   properties:

Как видите, мы объявили метод MyEvent в интерфейсе IFireClassEvents, который и будет являться нашим событием, которое мы будем «посылать» клиентскому приложению. Я оставил этот метод без параметров, а тип возвращаемого результата сделал булевским. Будем считать это маленьким капризом. Вы вольны описать этот метод, как вам будет угодно.

Далее продолжаем редактировать ODL-файл. В описании нашего кокласса MyInterface нужно добавить одну строку:

[ uuid(D46238C6-2277-11D5-964D-00001CDC1022) ]
coclass MyInterface
{
   [default] dispinterface IMyInterface;
   [default,source] interface IFireClassEvents;
};

Замечаем отличия? Конечно! Появилось новое служебное слово source. Что оно означает? В MSDN написано, что «атрибут [source] указывает, что член кокласса, свойство или метод - это источник событий. Для членов кокласса этот атрибут означает, что этот член вызовется раньше, чем выполнится». А также есть такая фраза: «В свойстве или методе этот атрибут указывает, что член возвращает объект или VARIANT, который является источником событий. Объект реализует интерфейс IConnectionPointContainer». Думаю, с этим все ясно. Сохраните сделанные изменения и откомпилируйте ODL-файл. Если вы все сделали правильно, то ошибок не будет.

Для каждой точки соединения, реализованной в нашем классе CMyInterface, мы должны объявить connection point part, которая реализует точку соединения. Если вы реализуете одну или более точек соединения вы также должны объявить простую карту соединений в вашем классе. Карта соединений - это таблица точек соединения, поддерживаемых ActiveX-контролом. Наш пример демонстрирует простую карту соединений и одну точку соединения. Для этого откройте файл объявления класса MyInterface.h и сразу после макроса DECLARE_INTERFACE_MAP() добавьте нижеприведенный код:

DECLARE_CONNECTION_MAP()

BEGIN_CONNECTION_PART(CMyInterface,ObjCP)
   CONNECTION_IID(IID_IFireClassEvents)
END_CONNECTION_PART(ObjCP)

Таким образом мы объявляем карту соединений. BEGIN_CONNECTION_PART и END_CONNECTION_PART - это макросы, объявленные во встроенном классе и наследуемые от CConnectionPoint, который реализует эту точку соединения. Если вы хотите переопределить какую-либо функцию класса CConnectionPoint или добавить функцию-член вашего родителя, тогда объявите её между двумя этими макросами. К примеру, макрос CONNECTION_IID, расположенный между двумя этими макросами, переопределяет функцию CConnectionPoint::GetIID.

Я буду немного непоследователен, однако попрошу вас сразу, раз уж вы редактируете данный заголовочный файл, подняться к объявлению класса CMyInterface и перед его объявлением вставить следующие строки:

extern
const IID IID_IFireClassEvents;
interface IFireClassEvents : public IDispatch {};

Первая строка объявляет константу IID_IFireClassEvents, которую мы использовали в макросе CONNECTION_IID(IID_IFireClassEvents). Ведь все должно работать без ошибок. Однако перед описанием этой константы стоит служебное слово extern. Это значит, что она уже где-то объявлена. Поэтому я и сказал, что слегка непоследователен. Здесь все правильно. Сейчас мы закончим с заголовочным файлом и объявим этот идентификатор интерфейса в файле реализации класса CMyInterface.

Вторая строка есть объявление интерфейса. Теперь сохраните файл MyInterface.h и закройте его.

Следующим этапом добавим в файл MyInterface.cpp то, о чем собственно говорили только что выше. Найдите в коде декларацию идентификатора IID_IMyInterface и сразу после него вставьте следующие строки (только не забывайте вставлять правильные числовые значения, если вы используете uuid, отличный от того, что создала мне утилита guidgen.exe):

#pragma warning( disable : 4211)static
const IID IID_IFireClassEvents =
//(F7222740-2296-11d5-964D-00001CDC1022)
{ 0xf7222740, 0x2296, 0x11d5, { 0x96, 0x4d, 0x0, 0x0, 0x1c, 0xdc, 0x10, 0x22 } };
#pragma warning( default : 4211)

Обратите внимание на две директивы препроцессора, которые окаймляют данное объявление. Первая из них гасит ненужное предупреждение компилятора, а вторая снова его разрешает. Теперь добавьте в карту интерфейсов интерфейс IConnectionPointContainer (MyInterface.cpp):

BEGIN_INTERFACE_MAP(CMyInterface, CCmdTarget)
   INTERFACE_PART(CMyInterface, IID_IMyInterface, Dispatch)
   INTERFACE_PART(CMyInterface, IID_IConnectionPointContainer, ConnPtContainer)
END_INTERFACE_MAP()

И наконец, сразу за картой интерфейсов вставьте карту соединений:

BEGIN_CONNECTION_MAP(CMyInterface, CCmdTarget)
   CONNECTION_PART(CMyInterface,IID_IFireClassEvents,ObjCP)
END_CONNECTION_MAP()

Затем добавьте в конструктор нашего класса вызов функции EnableConnections. Эта функция является недокументированной функцией класса CCmdTarget, однако если вы не вызовете её из конструктора класса, работающего с Connection point и являющегося потомком CCmdTarget , то у вас ничего не получится.

CMyInterface::CMyInterface()
{
   EnableAutomation();
   EnableConnections();

   // To keep the application running as long as an OLE automation 
//   object is active, the constructor calls AfxOleLockApp.

   AfxOleLockApp();
}

Сохраните редактируемый файл и постройте наш проект. Если вы делали все правильно, то не должно быть ни ошибок, ни предупреждений. На данный момент у нас готов основной каркас. Займемся реализацией непосредственно самих функций. Однако сначала я хотел бы обратить ваше внимание на следующий факт. Я думаю, ни для кого не секрет, что СОМ-сервер может иметь сразу нескольких клиентов. Может случиться так, что этот сервер должен посылать событие клиентам в ответ на какое-либо действие пользователя. Например, сервер имеет графический интерфейс, и когда пользователь выбирает меню Файл, сервер должен уведомить ВСЕХ ЗАИНТЕРЕСОВАННЫХ клиентов об этом. Естественно возникает 2 вопроса:

1. Каким образом сервер сможет послать событие сразу всем клиентам.
2. Как определить, какой клиент заинтересован в получении событий, а какой нет?

Начнем со второго вопроса. Для этих целей интерфейс IConnectionPoint предусматривает специальные методы подписки на события Advise и Unadvise. С помощью первого из них клиент сообщает серверу, что он желает получать уведомления относительно какого-либо события, а вторая функция, наоборот, сообщает серверу, что данный клиент больше в таких сообщениях не нуждается. Соответственно, сервер должен иметь некий список, в который он заносит «адреса» клиентов, подписанных на те или иные сообщения. И из которого он потом будет удалять отписавшихся клиентов. Таким образом, когда серверу нужно будет послать некое событие клиентам, то он в цикле пробежится по этому списку и отправит сообщения всем заинтересованным клиентам. Это и есть ответ на первый вопрос. Теперь приведем процедуру, которая реализует все выше сказанное. Вставьте её код в файл MyInterface.cpp а также не забудьте объявить её в MyInterfcae.h.

void CMyInterface::FireEvent()
{
   const CPtrArray* pConnections=m_xObjCP.GetConnections();

   int nConnections=pConnections->GetSize();

   for (int i=0;i<nConnections;i++)
   {
      IDispatch* pClient=(IDispatch*)(pConnections->GetAt(i));
      if (pClient)
      {

         VARIANT varResult;

         DISPPARAMS disp={0,0,0,0};

         HRESULT hr = pClient->Invoke(0x1,
                        IID_NULL,
                        LOCALE_USER_DEFAULT,
                        DISPATCH_METHOD,
                        &disp,
                        &varResult,
                        NULL,
                        NULL);

      }
   }
}

Итак, что же мы имеем? Скажу сразу, что MFC сильно облегчила нам жизнь. Здесь const CPtrArray* pConnections=m_xObjCP.GetConnections(); мы объявляем указатель на CPtrArray и присваиваем ему значение полученное из m_xObjCP.GetConnections(). Вот и все. Теперь мы имеем указатель на список всех наших потенциальных клиентов. Объект m_xObjCP поддерживается средствами CCmdTarget и самостоятельно, «без нашего участия» заносит в список подписавшихся и удаляет из него отписавшихся клиентов. Дальше все просто: мы перебираем в цикле всех наших клиентов и с помощью метода Invoke «посылаем» им события.

Еще раз напомню: не забудьте добавить описание этой функции в наш класс. А теперь измените тело функции FireMyEvent, как показано ниже.

void CMyInterface::FireMyEvent()
{
   FireEvent();
}

Таким образом, мы заставим «входящий» метод сгенерировать событие. Сохраните все сделанные вами изменения и постройте проект. Ошибок быть не должно. После чего найдите полученную DLL и с помощью утилиты regsvr32.exe (или любого другого инструмента, способного вызвать функцию DllRegisterServer) зарегистрируйте её в вашей операционной системе. На этом с сервером все!

Часть 3. Реализация клиента.

Программа-пример Client

Теперь напишем клиента. Выполните пункты меню File->New и заполните опции согласно рисунку 8.

Обратите внимание на папки, куда я помещаю проекты клиента и сервера. Они оба должны находиться в одном каталоге. Жмите Ок, и в появившемся мастере выберите опцию создания диалогового приложения, см. рисунок 9, после чего жмите Finish.

Отредактируйте диалоговую форму. Чтобы она приняла вид, как на рисунке 10.

Сразу создайте обработчик для кнопки “Fire event”, он нам пригодится, а также для кнопки ОК. Теперь необходимо в функции InitInstance класса CPointClientApp добавить инициализацию СОМ. В нашем случае вполне сойдет инициализация для STA, поэтому воспользуемся функцией CoInitialize(NULL):

BOOL CPointClientApp::InitInstance()
{
   AfxEnableControlContainer();
   CoInitialize(NULL);

Сразу же добавьте в этот класс с помощью ClassWizard функцию ExitInstance, а в её обработчике поставьте деинициализацию СОМ:

int CPointClientApp::ExitInstance()
{
   CoUninitialize();return CWinApp::ExitInstance();
}

Все, с этим классом закончили. Сохраните все изменения. Следующим шагом мы должны хорошенько поработать с классом CPointClientDlg. Для этого откройте файл PointClientDlg.h, в котором находится определение этого класса. Сейчас мы снабдим компилятор информацией об интерфейсах нашего СОМ-сервера. Для этого добавьте в PointClientDlg.h до определения самого класса следующую строку (после чего постройте проект):

#import "..\Server\Debug\PointServer.tlb" no_namespace named_guids

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

Теперь давайте добавим в класс CPointClientDlg (файл PointClientDlg.h) две приватные переменные:

private:
   IMyInterfacePtr   m_MyInterface;
   DWORD         m_dwCookie;

Первая из них есть указатель на интерфейс нашего СОМ-сервера, который мы создавали несколько раньше. Тип IMyInterfacePtr любезно предоставила нам директива #import, после того как мы подключили файл PointServer.tlb. С помощью данного импорта мы приобрели много полезной информации о нашем сервере. Она находится в файлах PointServer.tlh и PointServer.tli, в том числе и определение IMyInterfacePtr. Изучите эти файлы на досуге и, возможно, вы откроете для себя что-то новое.

Вторая переменная (m_dwCookie) есть уникальный идентификатор, который вернет нам функция AfxConnectionAdvise. Помните, я уже рассказывал о механизме подписки клиентов на сообщения от сервера. Тогда мы говорили о функциях Advise и Unadvise интерфейса IConnectionPoint. Здесь же мы будем использовать аналоги этих функций - AfxConnectionAdvise и AfxConnectionUnadvise, предоставляемые библиотекой MFC. Так вот, m_dwCookie - это идентификатор нашей подписки, который вернет нам сервер в случае успешной регистрации нашего соединения. Зачем он нам нужен? Ну, хотя бы для того, чтобы отдать его серверу, когда мы пожелаем отписаться от принятия сообщений, ведь должен же сервер знать, кого он будет удалять из своего списка. Другими словами, m_dwCookie - это аналог того номерка, что дают вам злые тети в раздевалках, если вы сдаете одежду, при походах в театр, библиотеку и т.д. Сохраните сделанные нами изменения и закройте этот файл.

Теперь займемся файлом реализации класса CPointClientDlg. Для этого откройте файл PointClientDlg.cpp, найдите функцию OnInitDialog и строку в ней

// TODO: Add extra initialization here

Вот вместо этого напоминания мы сейчас и напишем наш код. Здесь будет находиться код загрузки СОМ-сервера, а также функция подписки на его события. Итак, вместо комментариев, указанных мастером вставьте следующие строки:

   EnableAutomation();
   UUID   uuid;
   m_MyInterface = NULL;

   uuid = __uuidof(MyInterface);
   m_MyInterface.CreateInstance(uuid);

   m_dwCookie = 0;
   BOOL Ret = AfxConnectionAdvise(
               m_MyInterface,
               DIID_IFireClassEvents,
               this->GetIDispatch(FALSE), // get the IDispatch assocaiated with Mainframe...
               FALSE, // donod addref
               &m_dwCookie ); // cookie to break connection later...

С помощью __uuidof мы получим UUID интерфейса IMyInterface, который затем подставим в функцию CreateInstance. Таким образом, мы вызовем загрузку нашего СОМ-сервера.

После того, как функция CreateInstance будет успешно выполнена, мы подпишемся на сообщения от интерфейса IFireClassEvents с помощью функции AfxConnectionAdvise. В случае корректного завершения которой мы получим наш идентификатор - m_dwCookie. Приведенный код не содержит механизма обработки возможных ошибок, чтобы не загромождать главную идею, которую мы сейчас рассматриваем. В случае необходимости вы можете добавить его сами. Ну вот, к тому моменту, как мы увидим на экране диалог нашего клиента, СОМ-сервер будет уже загружен и готов посылать нам событие, что мы реализовали в его коде.

Сразу же добавим код отписки от событий, который вставим в обработчик нажатия кнопки ОК:

void CPointClientDlg::OnOK()
{
   if(m_MyInterface)
   {
      AfxConnectionUnadvise( m_MyInterface,
                        DIID_IFireClassEvents,
                        this->GetIDispatch(FALSE),
                        FALSE,
                        m_dwCookie );
      m_MyInterface = NULL;
   }

   CDialog::OnOK();
}

Здесь все предельно ясно. Передавая нашу «куку» (m_dmCookie) функции AfxConnectionUnadvise, мы тем самым отписываемся от рассылки событий. После чего делаем m_MyInterface = NULL, чем вызываем выгрузку СОМ-сервера.

Последним штрихом добавим код в обработчик второй нашей кнопки:

void CPointClientDlg::OnFireevent()
{
   m_MyInterface->FireMyEvent();
}

Сохраните все сделанные нами изменения и постройте проект. Если все сделали правильно, то должны были получить 2 сообщения об ошибке, рисунок 11.

Все правильно. Для того, чтобы эти функции не вызывали ошибок нужно сделать следующее подключение:

#include <afxctl.h>

Попробуйте снова. Сейчас все должно быть без ошибок.

Устали? Я тоже. Подождите, осталось совсем немного. Сейчас мы реализуем код функции, что будет вызывать у нас сервер, и на этом закончим. Итак, откройте файл PointClientDlg.h и сразу после декларации карты сообщений вставьте ещё несколько определений:

DECLARE_DISPATCH_MAP()
DECLARE_INTERFACE_MAP()

BOOL   OnMyEvent();

Таким способом вы объявите две карты: DISPATCH MAP и INTERFACE MAP, которые нам необходимы. А также объявите обработчик OnMyEvent события MyEvent. Сохраните, сделанные изменения и закройте файл.

Теперь откройте файл реализации класса CPointClientDlg, PointClientDlg.cpp, и сразу после окончания реализации карты сообщений вставьте следующий код:

BEGIN_DISPATCH_MAP(CPointClientDlg, CDialog)
   DISP_FUNCTION_ID(CPointClientDlg, "MyEvent",1, OnMyEvent, VT_BOOL, VTS_NONE)
END_DISPATCH_MAP( )

BEGIN_INTERFACE_MAP(CPointClientDlg, CDialog)
   INTERFACE_PART(CPointClientDlg, DIID_IFireClassEvents, Dispatch)
END_INTERFACE_MAP()


BOOL CPointClientDlg::OnMyEvent()
{
   AfxMessageBox("Event!!!!!!!!");
   return TRUE;
}

Что же это означает?

Во-первых, между макросами BEGIN_DISPATCH_MAP и END_DISPATCH_MAP , с помощью DISP_FUNCTION_ID по номеру метода (1 - см. ODL-файл сервера) мы указываем имя события (MyEvent), его обработчик (OnMyEvent), тип возвращаемого значения (VT_BOOL), а также тип аргументов (VTS_NONE - в данном случае их нет).

Далее идет реализация интерфейсной карты и реализация функции обработчика события OnMyEvent.

На этом, пожалуй, все. Сохраните файл, постройте проект и запустите на выполнение нашего клиента. Если вы все делали правильно, то по нажатию на кнопку “Fire Event”, должны получить результат как на рисунке 12.

На этом я закончу. Надеюсь, что этот материал кому-то окажет помощь в трудную минуту.

/ / / / / ВОПРОС-ОТВЕТ / / / / / / / / / / / / / / / /

Как узнать имя exe-файла выполняемой программы?

Функция GetModuleFileName возвращает полный путь и имя исполняемого файла. Пример ее использования смотри ниже.

TCHAR FileName[MAX_PATH + 1]; // буфер для имени файла
GetModuleFileName(NULL, FileName, MAX_PATH + 1);

Первый параметр функции GetModuleFileName - дескриптор модуля, для которого требуется получить имя. Если в качестве первого параметра указан hInstance программы или NULL, возвращается имя выполняемой программы. Если же указать дескриптор загруженного модля (DLL), который возвращается функциями LoadLibrary, LoadLibraryEx или GetModuleHandle, возвращается имя этой DLL. Кроме функции GetModuleFileName, существует функция GetModuleFileNameEx, позволяющая получить имя модуля, загруженного в адресное пространство другого процесса.

/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /

Это все на сегодня. Пока!

Алекс Jenter   jenter@rsdn.ru
Красноярск, 2001. Рассылка является частью проекта RSDN.