Читать «Применение Windows API» онлайн - страница 36
А. И. Легалов
Итак, теперь мы имеем подсчет ссылок, агрегацию и все прочее. Мораль истории:
Нет ничего святого, что касается OLE. Это может быть сделано лучше!
Но мы все же можем иметь пирог и есть его? Другими словами, можно формировать «интеллектуальное OLE» на вершине «другого OLE»? Ваша ставка! Идите прямо к следующей обучающей программе.
Оболочка из классов для OLE
Англоязычный оригинал находится на сервере компании Reliable Software
Построив интеллектуальное OLE на вершине старого, Вы узнаете другое OLE
Прежде всего Вы должны сообщить миру, что собираетесь использовать OLE. Имеется небольшой класс, который будет делать это за Вас. Только внедрите объект этого класса в некоторый высокоуровневый сконструированный объект прежде, чем Вы что-либо сделаете с OLE и удалите его после того, как отработаете с OLE. В Windows программе первоосновой для UseOle является «Контроллер».
class UseOle {
public:
UseOle() { OleInitialize (0); }
~UseOle() { OleUninitialize (); }
};
class Controller {
public:
Controller(HWND hwnd, CREATESTRUCT* pCreate);
~Controller() { PostQuitMessage(0); }
void Paint(HWND hwnd);
private:
UseOle useOle;
};
Затем Вы должны создать OLE объект, который является поставщиком интерфейсов. Абстрактный класс CoObject объявляет метод AcquireInterface. Фактический класс SObject (интеллектуальный объект) обеспечивает одну специфическую реализацию CoObject, которая использует, внутри себя, позорящий OLE IUnknown.
class CoObject {
public:
virtual void* AcquireInterface (IID const& iid) = 0;
};
class SObject: public CoObject {
public:
SObject(CLSID const& classId, bool running = false);
~SObject() {
if (_iUnk) _iUnk-> Release ();
}
void* AcquireInterface(IID const& iid);
private:
IUnknown * _iUnk;
};
Давайте взглянем на реализации конструктора и метода AcquireInterface.
Конструктор получает объект, вызывая функцию API GetActiveObject и/или CoCreateInstance. Различие между ними в том, что GetActiveObject пытается овладеть уже выполняющимся объектом, в то время как CoCreateInstance пробует то же самое, но, если это терпит неудачу, то запускает любой exe-шник, необходимый для выполнения этого объекта. Некоторые объекты фактически определяют предпочтение: они хотят, чтобы новый сервер был заново запущен каждый раз, когда вызывается CoCreateInstance. GetActiveObject позволяет Вам обойти это.
Обратите внимание, что это — только один пример того, как Вы получаете доступ к OLE объектам. Вы можете захотеть поиграть с некоторыми из параметров. Например, я передаю CLSCTX_SERVER как параметр в CoCreateInstance. Это даст мне уверенность, что объект будет жить в отдельном от клиента процессе. Во многих случаях вам лучше иметь объект как сервер в процессе на основе DLL, которая загружается в адресное пространство клиента. Для больших подробностей ищите описание CoCreateInstance в вашей справке.
