Обертка для автоматизации

 Автоматизация

Перевод А. И. Легалова

Англоязычный оригинал находится на сервере компании Reliable Software

Мне бы хотелось получить море информации из запущенной копии Microsoft Developers Studio. Это должно быть простой задачей, т.к. DevStudio, подобно многим другим приложениям MS, предоставляет его интерфейсы через OLE Автоматизацию. Не столь просто! Как Вы увидите, Microsoft решил, что клиенты интерфейсов автоматизации VC ++ будет или использовать Visual Basic, или внутренних умных мастеров DevStudio. Я, с другой стороны, люблю программировать на C++ (Вам не кажется, что Microsoft Visual C++ должен быть переименован в Microsoft Visual MFC Wizard? Это принизило C++ до роли языка сценариев для MFC.)

В любом случае, когда я выяснил, как надо делать, остальное оказалось не быть слишком трудным. Вы только должны выяснить, где вся необходимая информация сохраняется в реестре. В частности IID всех интерфейсов. Совет: используйте OLE-COM Object Viewer, который поставляется с VC ++, чтобы просмотреть библиотеки типов. Было бы вообще великолепно, если бы Microsoft предоставлял исходные файлы или obj файлы с определениями идентификаторов интерфейсов. В существующей же ситуации я должен копировать их из Object Viewer'а и вставлять их в нужное место. Ниже приводится пример.

static const IID IID_IApplication = { 

 0xEC1D73A1, 0x8CC4, 0x11CF, { 0x9B, 0xE9, 0x00, 0xA0, 0xC9, 0x0A, 0x63, 0x2C }

};

Итак, как получить управление выполняющейся копией DevStudio? В начале вы должны создать OLE объект. Для этого необходим идентификатор класса этого объекта. Вы можете получить идентификатор класса от системы (эта информация хранится в реестре), если знаете программный идентификатор. Программный идентификатор, устроен так чтобы читаться человеком. Конечно, каждый человек знает, что Developer Studio идет под именем "MSDEV.APPLICATION". Это так просто.

Имея идентификатор класса, мы можем создать наш SObject. Мы передаем значение параметра запуска как true, потому что хотим соединиться с выполняющейся копией MSDEV.APPLICATION, если это возможно. Получение интерфейса из SObject столь же просто как создание экземпляра шаблона SObjFace с соответствующими параметрами. Итак, нашей отправной точкой будет, интерфейс к приложению.

CLSID idMsDev;

HRESULT hr = ::CLSIDFromProgID(L"MSDEV.APPLICATION", &idMsDev);

if (FAILED (hr)) throw HEx(hr, "Couldn't convert prog id to class id");

SObject obj(idMsDev, true);

SObjFace<IApplication, &IID_IApplication> app(obj);

Обратите внимание, что строка, которую Вы передаете к CLSIDFromProgID, должна использовать кодировку Unicode. Помещение L перед строковым литералом обеспечивает это.

Я надеюсь, что Вы можете оценить простоту этого кода. Он почти столь же прост, как и его VB эквивалент.

Dim app as Application

Set app = GetObject(, "MSDEV.APPLICATION")

if (app = NULL)

 Set app = CreateObject("MSDEV.APPLICATION")

Теперь давайте что-нибудь сделаем с этим интерфейсом. Так случилось, что IApplication имеет член Visible, который Вы можете установить или получить. Когда Вы устанавливаете Visible в истину, окно приложения становится видимым. Ниже приводится синтаксис для «установки» члена. Обратите внимание, что в OLE Вы должны использовать обозначения с именами VARIANT_BOOL и VARIANT_TRUE вместо bool и true. Это делается ради совместимости с Basic (что делает Билла счастливым).

VARIANT_BOOL b = VARIANT_TRUE;

app->put_Visible(b);

Как я узнал, что IApplication имеет член Visible? Хороший вопрос! Имеется подкаталог objmodel в VC ++, в каталоге include, где Вы можете отыскать такие файлы как Appauto.h, которые содержат строки, подобные одной из показанных ниже. Вы можете проводить выборочное изучение, чтобы интерпретировать эти файлы. Их критика связана с (глупым!) требованием, чтобы они включались как в C, так и в C++ код. А Microsoft не захотела поддерживать два набора заголовочных файлов, поэтому здесь мы поступаем так.

STDMETHOD(get_Visible)(THIS_ VARIANT_BOOL FAR* Visible) PURE;

STDMETHOD(put_Visible)(THIS_ VARIANT_BOOL Visible) PURE;

Так, что же мы делаем дальше, когда приложение в наших руках? Как насчет выяснения того, какой документ является в настоящее время активным? Используя интерфейс IApplication в качестве источника, мы можем создавать другой OLE объект, который представит активный документ. Этот специфический OLE объект, SActiveDocument, может использоваться как источник нескольких интерфейсов, одним из которых является IGenericDocument. Мы захватываем этот интерфейс стандартным способом — создавая объект с помощью шаблона SObjFace. SActiveDocument, подобно всем нашим объектам OLE/COM, наследует от CoObject, исходные интерфейсы.

IGenericDocument имеет член FullName, который может быть получен, вызовом метода get_FullName. К сожалению, совместимость с Basic снова наносит удар: результат передается в форме BSTR, или Basic строки. Я создал два вспомогательных класса BString и CString, чтобы заботиться о этой сверхъестественности. В частности BString удостоверяется, что строка освобождена, используя при этом функцию API SysFreeString.

SActiveDocument docObj(app);

if (docObj) {

 SObjFace<IGenericDocument, &IID_IGenericDocument> doc(docObj);

 BString bPath;

 doc->get_FullName(bPath.GetPointer());

 CString path(bPath);

 canvas.Text(20, y, "Active Document:");

 canvas.Text (200, y, path);

}

Это типичная ситуация для OLE Автоматизации. Используя интерфейсный метод одного приложения (app в данном случае) Вы овладеваете другим объектом (docObj) и его собственными интерфейсами. Для каждого такого метода, возвращающего объект, мы создадим новый класс интеллектуальных указателей, которые отличаются только возможностями их конструкторов. Например, имеется класс SActiveDocument.

class SActiveDocument: public DispObject {

public:

 SActiveDocument(SObjFace<IApplication, &IID_IApplicationication> &app) {

  HRESULT hr = app->get_ActiveDocument(&_idisp);

  if (FAILED (hr)) throw HEx(hr, "get_ActiveDocument failed");

 }

};

Обратите внимание, что базовый класс SActiveDocument — не SObject. Это новый класс DispObject. Он почти подобен SObject с одним лишь различием внутри: вместо использования указателя на IUnknown, он использует указатель на IDispatch. Это имеет значение? Реально — нет, я мог бы использовать SObject и все, работало бы также. За исключением того, что IDISPATCH может использоваться для большего чем запрос только других интерфейсов. Он может использоваться для динамической диспетчеризации вызовов. Так как наша программа написана на C++, и она знает все предоставленные интерфейсы, мы в действительности можем не использовать динамическую диспетчеризацию. Но имеются ситуации, в которых Вы должны дать пользователю возможность решить в реальном времени: какой объект загрузить и какой метод вызвать. Интерпретаторы и языки сценариев позволяют делать это. В частности, Visual Basic, являющийся инструментом для написания сценариев имеет такие функциональные возможности.

Ниже представлена скелетная реализация DispObject, которая демонстрирует эту возможность. Она также объясняет, почему мы говорили о таких «членах», как Visible или FullName при обсуждении интерфейсов. В VB они фактически появляются как элементы данных, или как реквизиты, объектов. Здесь, я реализовал диспетчерский метод GetProperty, который используется, чтобы загрузить значение любого свойства, по его DISPID. И Вы можете получать DISPID любого свойства или метода, если Вы знаете его имя. Метод GetDispId будет делать это для Вас. Подобным способом, Вы можете реализовать и PutProperty, а также Invoke, который может использоваться, чтобы вызвать любой метод по его DISPID. Я оставляю это как упражнение для читателя.

class DispObject: public CoObject {

public:

 DispObject(CLSID const& classId) : _iDisp(0) {

  HRESULT hr = ::CoCreateInstance(classId, 0, CLSCTX_ALL, IID_IDispatch, (void**)&_iDisp);

  if (FAILED(hr)) {

   if (hr == E_NOINTERFACE) throw "No IDispatch interface";

   else throw HEx(hr, "Couldn't create DispObject");

  }

 }

 ~DispObject() {

  if (_iDisp) _iDisp->Release();

 }

 operator bool() const { return _iDisp != 0; }

 bool operator!() const { return _iDisp == 0; }

 DISPID GetDispId(WCHAR* funName) {

  DISPID dispid;

  HRESULT hr = _iDisp->GetIDsOfNames(IID_NULL, &funName, 1, GetUserDefaultLCID(), &dispid);

  return dispid;

 }

 void GetProperty(DISPID propId, VARIANT& result) {

  // In parameters

  DISPPARAMS args = { 0, 0, 0, 0 };

  EXCEPINFO except;

  UINT argErr;

  HRESULT hr = _iDisp->Invoke(propId, IID_NULL, GetUserDefaultLCID(), DISPATCH_PROPERTYGET, &args, &result, &except, &argErr);

  if (FAILED (hr)) throw HEx(hr, "Couldn't get property");

 }

 void* AcquireInterface(IID const & iid) {

  void* p = 0;

  HRESULT hr = _iDisp->QueryInterface(iid, &p);

  if (FAILED(hr)) {

   if (hr == E_NOINTERFACE) throw "No such interface";

   else throw HEx(hr, "Couldn't query interface");

  }

  return p;

 }

protected:

 DispObject(IDispatch * iDisp) : _iDisp(iDisp) {}

 DispObject() : _iDisp(0) {}

protected:

 IDispatch* _iDisp;

};

Ниже приводится небольшая иллюстрация динамической диспетчеризации. Конечно, тот же самый результат мог быть получен непосредственно, если вызвать метод get_Name интерфейса IGenericDocument. Мы рассмотрим этот непосредственный метод, использующий таблицу виртуальных фунций через мгновение, чтобы получить полный путь документа.

// Use docObj as a dispatch interface

DISPID pid = docObj.GetDispId(L"Name");

VARIANT varResult;

::VariantInit(&varResult);

docObj.GetProperty(pid, varResult);

BString bName(varResult);

CString cName(bName);

canvas.Text(20, y, "Name:");

canvas.Text(200, y, cName);

Это показывает, как Вы получаете путь, используя таблицу виртуальных функций (vtable).

SObjFace<IGenericDocument, &IID_IGenericDocument> doc(docObj);

BString bPath;

doc->get_FullName(bPath.GetPointer());

Теперь у Вас не должно быть каких-либо проблем при понимании кода, который определяет номер строки, на которой пользователь позиционировал курсор.

BString bType;

doc->get_Type(bType.GetPointer());

if (type.IsEqual("Text")) {

 SObjFace<ITextDocument, &IID_ITextDocument> text (docObj);

 SSelection selObj(text);

 SObjFace<ITextSelection, &IID_ITextSelection> sel(selObj);

 long line;

 sel->get_CurrentLine(&line);

 canvas.Text(20, y, "CurrentLine:");

 char buf[10];

 wsprintf(buf, "%ld", line);

 canvas.Text(200, y, buf);

}

SSelection — это DispObject, который может быть получен, вызовом метода get_Selection интерфейса текстового документа.

class SSelection: public DispObject {

public:

 SSelection(SObjFace<ITextDocument, &IID_ITextDocument>& doc) {

  HRESULT hr = doc->get_Selection(& _iDisp);

  if (FAILED(hr)) throw HEx(hr, "get_Selection failed");

 }

};

У Вас могут быть небольшие трудности, если это — ваш первый контакт с OLE (преуменьшение!). Поэтому, ниже подводятся некоторые итоги, которые суммируют различные действия, позволяющие упростить задачу Автоматизации. Обратите внимание, что это — клиентская сторона уравнения. Если Вы хотите, чтобы ваше приложение было сервером Автоматизации, то ожидайте некоторых усложнений. Хорошо то, что имеется большое количество литературы по этим вопросам.

Итак здесь изложено то, что Вы должны сделать.

• Исследование

 ○ Проведите поиск в вашем реестре (используя RegEdt32 или OLE/COM object viewer) чтобы найти ProgID приложения, которым Вы хотите овладеть. HKEY_CLASSES_ROOT — отправная точка. Вы увидите там такие ключи как Word.Application, Excel.Application и многие другие.

 ○ Отыщите библиотеки типов, используя OLE/COM object viewer. Они предоставят идентификаторы классов и идентификаторы интерфейсов, которые Вы должны скопировать и вставить в ваш код.

 ○ Найдите заголовочные файлы для этих интерфейсов.

• В вашей программе: Преобразуйте ProgID в ClassID.

• Чтобы соединяться с выполняющимся приложением или активизировать новый экземпляр, создайте SObject, используя ClassID.

• Получите интерфейс IApplication из объекта (используйте шаблон IObjFace).

 ○ Используйте этот интерфейс, чтобы получить доступ к другим объектам внутри приложения. Для каждого такого объекта:

 ○ Объявите класс, наследующий от DispObject.

 ○ В его конструкторе используйте соответствующий get_* метод, чтобы получить доступ к внутреннему объекту.

 ○ Создайте объект этого класса, передавая его интерфейс родительскому объекту.

 ○ Получите соответствующий интерфейс из этого объекта используя шаблон IObjFace.

 ○ Вызовите соответствующие методы этого интерфейса.

Итак, во что бы это вылилось при подсчете ссылок OLE? Победите меня! Они должны были исчезнуть, если только использовать правильную инкапсуляцию. Ниже приведена диаграмма зависимостей классов. OLE объекты — слева, OLE интерфейсы — справа.


Во временя выполнения, Вы начинаете с SObject, представляющего программу, которую вы связываете. Затем обеспечиваете доступ из объекта к интерфейсу и от интерфейса к DispObject. Вы используете объекты как источники интерфейсов и интерфейсы для вызова специфических методов и получения других объектов.

В заключение. Вы можете загрузить исходный текст примера, который иллюстрирует применение этих методов.

Далее: Создание разделителя окон (сплиттера).
 

Главная | В избранное | Наш E-MAIL | Добавить материал | Нашёл ошибку | Наверх