[Supermax]

В этой теме обсуждаются вопросы контроля создания определенных СОМ объектов, разумеется для использования этого сервиса из под Автокада и не только.

Ну, вопросов на самом деле не один и не два, но по очереди, это первый.
В памяти компьютера висит несколько объектов одного класса. Надо определить их количество. Можно и на VBA или BVScript? или JScript, но надо.
Вопрос не простой, понимаю, но кто-то же наверное знает?

[Кулик Алексей aka kpblc]

По-моему, нереально. В лучшем случае (если СОМ-объект создает свой процесс) можно попытаться через перечисление процессов сделать. Решений такого уровня не видел (правда, и не искал особо).

[Supermax]

Да, решение и я не видел, хотя ссыка вроде есть.
Вот супер классный учебник.
http://www.xserver.ru/computer/sreda.../6/index.shtml

А теперь, что я нарыл.

1.

В COM не реализован сервис имен (Naming Services), аналогичный CORBA. Этот Corba-сервис позволяет получать ссылку на конкретный экземпляр объекта, созданный на сервере. Идентификация объекта при этом происходит по имени.

Вот от сюда:
http://www.rsdn.ru/article/com/COMvs.xml#E6JAC

Далее, от туда же:

Обычно необходимость такой функциональности встречается редко, так как COM придерживается отличных от Corba принципов взаимодействия с объектами. Но если такая функциональность вам необходима, то можно создать свой сервис имен. Для этого удобно воспользоваться функциональностью Singleton-объектов. Singleton-объект создает другие объекты и помещает их в массив, статический в простом случае, и динамический, или мап (объект, позволяющий ассоциировать одни значения с другими – в нашем случае имена объектов с указателями на их интерфейс) в более сложном случае. Один из методов этого Singleton-объекта принимает в качестве входного параметра имя и возвращает ассоциированный с ним объект. Простой пример, того, как это можно сделать с помощью ATL, находится на нашем сайте (http://www.rsdn.ru/article/corba/COMvsCORBA_code.xml) в электронной версии этой статьи. Там же приведен и Corba-вариант, использующий сервис имен.

Жирным выделил нужное.
Резюме.
Если создать объект типа Singleton или Моникер
(см. Использование моникера тут http://www.xserver.ru/computer/sreda...svc/6/32.shtml)
то, можно создать нечто (уж не знаю как назвать), что создаст собственное пространство имен, например для объекта WebBrowser.

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

Клиент передает Singleton-объекту значение какого-нибудь свойства контролируемого СОМ объекта (вместе с именем естественно) и Singleton-объект перелопатив все экземпляры, находит тот, у которого значение это свойства совпадает с запросом. Клиенту возвращается указатель на интерфейс или nil, в случае необнаружения такого состояния.

Когда тебе надо, к примеру, подключиться к экземпляру браузера, обрабатывающего страницу с определенного адреса, ты передаешь имя свойства LocationURL и нужный тебе адрес страницы, а Singleton-объект возвращает тебе указатель на интерфейс того экзкмпляра объекта, который занять этим делом.

Естественно у экземпляра появляется два клиента. Это не запрещено в СОМ. А наличие такого диспетчера как Singleton-объект, дает решение вопроса о продолжительности жизни СОМ объекта и своевременном клацаньи счетчика ссылок.

Ну и с количеством, тут и ежу понятно, можно пальцем посчитать имена.

Если объект зарегистрирован как единичный - дело не меняет. Ну будет в пространстве имен одно имя, но вот если экземпляр СОМ объекта не расчитан на работу с несколькими клиентами, тогда и Singleton-объект делать незачем.

Можно сделать такой Singleton-объект для СОМ объекта AutoCAD.Application и легко получать доступ к нужному Автокаду. И т.д.

[Supermax]

Это дальнейшее продвижение к реализации.
http://www.rsdn.ru/article/com/comintercept.xml

[Кулик Алексей aka kpblc]

Ээээ... А объясни, какая разница (принципиальная) между твоим вариантом и вариантом аккуратного отслеживания создания объектов внутри кода и принудительного их уничтожения?

[Supermax]

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

[Supermax]

Есть один пример.
Вот у меня несколько мониторов и я открыл два Автокада. Руками. Как связаться одному Автокаду с текущим рисунком другого? Ведь Getobject присоединиться к текущему объекту с указанным ProgID, а текущий-то тот, из которого это вызывается, то есть к самому себе. А если я три Автокада открою?

[Кулик Алексей aka kpblc]

Ага, а многодокументный режим придуман для кого?

[Supermax]

Ага, а на второй монитор, второй документ перетащить слабо?

[Supermax]

Offtop: Мне мысль пришла в голову, я взял и растянул окно Автокада на два монитора. Кнопок теперь можно натулить - уйму и два документа открывать. Один на одном мониторе, другой - на другом. Правда заголовки глаз режут, зато количеством органов управления приятно радует.

[Supermax]

Совершенно опухнув от изучения тонконстей маршалинга, в порядке бреда, в голову пришла мысль, а не сделать ли пул объектов типа WebBrowser?

Технология следующая:
При включении компьютера, из автозагрузки, запускается процесс, формирующий внутри себя динамический пул СОМ объектов с заглушками. Точнее, при включении только один такой объект. Класс объекта заранее определен - WebBrowser, причем определенной версии.

Когда какой-либо клиент, лезет в реестр, с целью создать в своем процессе СОМ WebBrowser, вместо указателя на shdocvw.dll, он получает указатель на нашу DLL, из которой загружается ему вместо объекта WebBrowser представитель, да не простой. Он если надо shdocvw.dll в этот процесс подгрузит (вдруг от туда функции клиенту понадобятся) и связь с уже созданным и ждущим своего клиента WebBrowser-ом установит.

Таким образом, получается, что все клиенты, которым нужен WebBrowser, получают его из нашего процесса, через представителя-заглушку.

По скольку объект был уже создан, его отдают первому клиенту и тут же создается новый поток, с новым WebBrowser-ом и его заглушкой.

Основной поток нашего процесса контролирует, чтобы всегда был только один свободный WebBrowser.

Ладно, сделали, что это нам дает?
Разместив в основном потоке нашего процесса специальный, нами сделанный СОМ - Singleton-объект. Который создает, нечто типа пространства имен для нашего процесса и заносит в него создаваемые WebBrowser-ы.
Установив с ним связь мы можем установить связь (естественно отмаршаленную) с любым из используемых WebBrowser-ов. Контролировать их события и вообще все, что нам нужно.

Какие тут могут быть подводные камни?

[Кулик Алексей aka kpblc]

Скажу честно - маршалинг лично мне пока не поддался в смысле изучения.
Вопрос даже не в том, что ты в таком случае в полной мере получишь DLL Hell (вдобавок тобою же и порожденный); вопрос звучит примерно так: "А смысл?"
Ты полагаешь, что в жизни понадобится только один процесс WebBrowser. А если запущено 2 (3, 4, 5...) процессов acad.exe или любых иных приложений, которые обрашаются к WebBroswer'ам? А если эти WebBrowser'ы каждому из них нужны?
Возникает вопрос разделения пространств имен. И, как я понимаю, ты вернешься к тому, с чего начал.

[Supermax]

Нет, ты не понял. Пул - динамический, то есть всегда есть только N свободных и готовых к использованию компонентов СОМ, но, как только один из них передается своему клиенту, сразу после этого запускается создание нового образца. Размер пула увеличивается еще на один процесс с СОМ внутри. Я, для начала, сказал один уже есть. Это не в смысле всего один, а в смысле минимальное количество имеющихся в резерве свободных СОМ. И пул этот, не совсем классический пул, где все СОМ создаются сразу и перераспределяются.

Любой программе, пожелавшей работать с WebBroswer, тут же будет предоставлен ее собственный экземпляр, только вот создан он будет не в процессе и потоке клиента, а в нашем процессе и нашем потоке.

А пространство имен нужно, чтобы иметь возможность обращения к уже задействованному экземпляру СОМ WebBroswer.

[Supermax]

Представители-заглушки WebBroswer'ам не нужны. И главная версия - {8856F961-340A-11D0-A96B-00C04FD705A2}, и версия -1 - {EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B} имеют ThreadingModel - Apartment, а это, цитирую вот от сюда: http://it.kgsu.ru/VC/vc_0162.html

Модель разделенных потоков (apartment-threading model) позволяет всем клиентам получать прямой указатель на интерфейс компонента, не прибегая к услугам представителя/заглушки. Отделение (apartment) - это логическая структура для параллельной работы потоков, которая создается при вызове потоком API-функции CoInitializeEx() для инициализации библиотеки СОМ. Отделение связывается с одним или несколькими потоками и одним или множеством СОМ-объектов. Поскольку все объекты отделения поддерживают модель разделенных потоков, все потоки в этом отделении получают прямые указатели интерфейса на все его объекты.

Хотя нам надо маршалить в другие процессы и не известно, может и понадабятся.