перенос в excel

[Хакер]

Не были, а есть.

Сам по себе термин COM-dll — кривой. Хороший, правильный термин — COM-сервер.
Так вот COM-сервер — это «некто», кто порождает и отдаёт тебе ссылки на COM-объекты.

Бывают разные виды COM-серверов, и один из них, — внутрипроцессный (inprocess), — реализуется в виде отдельного PE-файла (это может быть dll, ocx, cpl и тому подобное), который подгружается в АП процесса.

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

Кроме того, при использовании внутрипроцессных COM-серверов, COM-клиент должен ещё и найти PE-файл, внутри которого реализован COM-сервер. Найти и загрузить его.

Технология ActiveX построена над COM и документирует некоторые вещи:

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

Первое обеспечивается за счёт IDispatch, второе — благодаря TLB, а третье зиждется на регистрации COM-серверов в реесте и инкапсуляции нудного процесса загрузки COM-сервера + создания COM-объекта внутрь функции CoCreateInstance.

Таким образом, ActiveX-сервер это COM-сервер, который поддерживает три этих момента. А если конкретно: это COM-сервер, внутри которого лежит TLB, который умеет регистрировать сам себя в реестре и объекты которого поддерживают IDispatch (и возможно ITypeInfo).

Если что-то из этого не поддерживается, то COM-сервер вряд ли можно назвать ActiveX-сервером.

В то же время, COM-сервер — ничуть не устаревшее явление. Если возможности и техники, даруемые технологией ActiveX, не нужны, можно не реализовывать их поддержку и создавать обычный COM-сервер с product-specific-способом создания объектов.

Вот например DX-овые библиотеки — это внутрипроцессный COM-серверы. Но они не являются ActiveX-серверами. Нельзя создать экземпляр класса Direct3D вызовом CoCreateInstance. Класс Direct3D не зарегистрирован в реестре как создаваемый. Но экземпляр этого класса можно создать вызовом экспортируемой функции Direct3DCreate8 из библиотеки d3d8.dll, внутри которой реализован COM-сервер.

Так что ActiveX-сервер является таким же частным случаем COM-сервера, каким является COM-сервер, реализованный в виде DLL, по отношению к библиотеки DLL вообще.

VB по умолчанию создаёт ActiveX-сервера, то есть COM-сервера, поддерживающие то, что должен поддерживать сервер, желающий называться ActiveX-сервером.

Просто COM-сервер можно сделать с помощью FNDLL, пометив класс(ы) как PublicNotCreatable и экспортировав функцию, создающую экземпляр такого класса и возвращающего ссылку на него.

Тогда FNDLL убьёт экспорт ненужных функций (DllRegisterServer), потому как регистрировать нечего, библиотека станет нерегистрируемой, потеряет статус ActiveX-сервера и станет останется обычным COM-сервером.

Думаю, разжевал понятно.

[SLIM]

Нельзя создать экземпляр класса Direct3D вызовом CoCreateInstance

Разве ActiveX-эеземпляры класса создаются только CoCreateInstance? Точнее не так, разве только ActiveX-экземпляры создаются с помощью CoCreateInstance? Это по-моему чистый COM.

Тут действительно все описано так как я предполагал.
Вот еще мысли.

Компонент COM - это еще не DLL и не EXE и не что-то еще. Это прежде всего тот самый класс. Все остальное - это контейнеры классов.
COM был разработан для того чтобы отвязаться от какого-либо языка, составив кое-какие рамки. COM-компонент может быть и в виде EXE и не быть при этом ActiveX. Так как COM-языконезависим, нужно уметь передавать данные через границу процесса. Поэтому нужны специальные заглушки-преобразователи на обоих концах (которые по-моему можно сделать через MIDL+C++).

На мой взгляд, достаточным для того чтобы называть себя COM-сервером является
1. Уметь регистрировать\удалять себя в системе
2. Экспортировать реализовывать CoCreateInstance для того чтобы уметь создавать компонент, для этого помоему нужна функция CoGetClassObject, которая будет вызывать DllGetClassObject из самого сервера.

По-моему все. CoCreateInstance создаст все что нужно. После этого мы получим экземпляр класса который нам нужен.
А вот уже TLB, интерфейс IDispatch, Invoke - это уже отчина ActiveX. Но суть то - все те же интерфейсы и компоненты, просто куда круче уровень взаимодействия и абстракции.

Кстати, вот то что мы имеем в VB Property Set, Get - это все заслуги ActiveX. Точно мы с легкостью можем сделать
set ff=New ADODB.Recordset
Без всяких QueryInterface, Release и подобного - это все его же заслуга.

Если честно, но у меня складывается мнение,что ActiveX создан для VB\VBA, что дало невероятную простоту в работе, но падение в скорости

[Хакер]

SLIM, в твоём посте много глупостей.