В начале я проверяю, не хочет ли IE сказать мне этим вызовом, что происходит завершение его работы и я должен освободить его интерфейсы. Дальше – интересней. Я запрашиваю интерфейс IWebBrowser2, но не как обычно, через вызов QueryInterface, а посредством вызова метода QueryService, предварительно полученного интерфейса IServiceProvider.

Очередное отступление, на этот раз про необходимость таких странных манипуляций для решения, казалось бы, стандартной задачи. Интерфейс IServiceProvider предназначен для использования в следующих ситуациях.

Предположим, существует некое приложение-контейнер, которое использует несколько COM-серверов. У каждого из них, естественно, есть доступ к интерфейсам контейнера (посредством IObjectWithSite::SetSite, например). Но вот кому-то из COM-серверов потребовалось получить доступ к интерфейсам другого COM-сервера, также содержащегося в контейнере.

Как же ему решить эту задачу? Ведь стандартными средствами он до другого сервера никак не доберётся, поскольку контейнер, в соответствии с идеологией COM, не предоставляет доступ к интерфейсам содержащихся в нём объектов непосредственно через вызовы QueryInterface своих интерфейсов.

Для решения таких задач как раз и предназначен интерфейс IServiceProvider. Его единственный метод – QueryService – отличается от QueryInterface одним параметром – идентификатором сервиса. Фактически – это идентификатор одного из COM-компонентов, используемых приложением-контейнером. И когда COM-сервер хочет получить интерфейс другого сервера, используемого тем же клиентом, он просто вызывает вышеназванный метод с соответствующим идентификатором сервиса.

Клиент же, в свою очередь, просто определяет, какой из содержащихся в нём компонентов соответствует переданному идентификатору и вызывает его QueryInterface.

Возвращаясь к нашей задаче, легко заметить, что здесь аналогичная ситуация. Internet Explorer представляет собой зоопарк компонентов, где наш COM-сервер (т.е. плагин) – один из питомцев. Поэтому нам и приходится использовать вышеописанную технику для получения доступа к интерфейсам другого компонента (которым, в нашем примере, является WebBrowser Control).

Следующим в очереди на реализацию у нас стоит метод QueryStatus интерфейса IOleCommandTarget. Его текст выглядит следующим образом:

В начале необходимо удостовериться в корректности переданных данных. Затем мы просто запрашиваем текущий URL и, если его последние символы .htm или .html, делаем кнопку и пункт меню доступными, или недоступными в противном случае. Следует заметить, что в этот метод всегда должен передаваться только один элемент в массиве prgCmds, т.к. мы отвечаем только за одну кнопку и пункт меню.

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

Теперь остался последний штрих – регистрация нашего компонента в реестре. В первую очередь, необходимо корректно зарегистрировать наш плагин как COM-сервер. Я не буду описывать эту процедуру здесь, поскольку это лежит за рамками моей статьи, да и информации на эту тему немало. Остановимся подробнее на регистрации нашей DLL в качестве плагина для Internet Explorer.

Для этого необходимо создать следующий ключ в реестре:

В качестве <key root> может выступать либо HKEY_CURRENT_USER (в этом случае плагин будет доступен только текущему пользователю), либо HKEY_LOCAL_MACHINE (плагин будет доступен всем пользователям).

Теперь в нём необходимо создать следующие параметры: