помогите: как использовать COM-технологию?
 

Проблема состоит в том, что есть некое внешнее устройство, подключённое через USB, и есть библиотеки dll к нему (без заголовочных h-файлов!), причём в иструкции написано, что "Модули расширения являются COM объектами". Скажите, каким образом эти библиотеки можно подключить к своей программе?

Можно поробовать загрузить dll и вызвать из программы функции какие эти dll предоставляют

На сколько я понял, эти COM-компоненты нужно регистрировать в системе (т.е. в реестре), а потом как-то обращаться к ним из своей программы. Только пока не понял, каким образом эти библиотеки dll можно зарегистрировать в системе... Но основная проблема, видимо, заключается в том, как узнать название объекта (класса), которые нужно подключать (в частности из matlab).

у меня тоже похожие проблемы...

регистрировать длл библиотеки легко если они поддерживают регистрацию, насколько я понимаю не все поддерживают ее...

regsvr32 "C:\full path\somename.dll"

Как это работает? Ведь ДЛЛ обычно пишется на С/С++, а вызывать её можно например из Визуал Байзика, как ДЛЛ может обрабатывать вызовы этого языка?

Admiral, ВБ6 умеет произвольные функции из dll импортировать. Есть понятие конвенции вызова - каким образом надо вызывать функции (как класть параметры на стек и куда передавать управление). Для функций, экспортируемых их длл принята так называемая stdcall конвенция. Из любого языка, который эту конвенцию поддерживает (в том числе и вб) можно вызвать функцию на другом языке, поддерживающем её.

zl3p, Зарегистрируйте эти dll в системе и посмотрите, нет ли в них typelib'ов внутри. С помощью тулзы вроде этой: http://www.aivosto.com/activexplorer.html (по-моему, в VS и VB есть стандартный инструмент для этого) Давно, не дружил с COM, так что не помню, чем это лучше делать. Если typelib есть (а в любом б-м. нормальном компоненте они будут), то никакие h файлы не нужны - idl можно сгенерить по данным typelib. А если компонент ещё и IDispatch поддерживает, то можно будет легко вызывать любые методы вообще ничего не генеря. Наверняка matlab всё через IDispatch в любом случае вызывает.

Я слышал про stdcall но в контексте написания ДЛЛ в Делфи, что б не возникало проблем у разработчиков С/С++.
Уходящая не выгодная технология?

А подключать ДЛЛ в ВБ 6 вижу смысл исключительно в тех случаях, когда базовыми возможностями решить задачу не возможно, а большая часть проекта уже есть. Для таких целей выгоднее использовать ОСХ или ДЛЛ? Ведь ДЛЛ предназначалась для того что уменьшить использование ресурсов программами и использовать общие функции в одних ДЛЛ.

Dll написанная на C как правило должна вызываться как stdcall из любого языка: С, Delphi, C++

Никогда не описывал dll как COM объект. Просто не вижу смысла. Мне всегда хватало просто экспортировать требуемые функции.
Т.е. просто удобно вынести в dll код который написан один раз и дальше будет использоваться ноднократно: алгоритмы шифрования, расчета контрольных сумм и т.д.

Нет, просто я под unix (freebsd, linux) сейчас только пишу, ибо серверный софт.

OCX это такая очень спецальная длл (которая, фактически является activex компонентом -> COM-сервером). Но вообще-то, я думаю, из вб пофигу, что вызывать - главное чтоб удобно было и работало. Всё равно на vb сейчас никто не пишет приложений под распространение, только под себя (лично или в рамках компании).

Тогда ОСХ удобнее - кинул на форму, а всё остальное тебе подскажет ОПП.
Например кинул Syper.OCX и когда в коде пишеш syper ставиш точку тебе уже функцыи и процедуры с подсказками. Обратная сторона в том что избыток ресурсов и были случаи у некоторых пользователей выскакивало сообщение при загрузки проги что Для ДЛЛ же надо прописать каждую по особому либо Declare Function либо Declare Sub, далее какую именно функцию, какие переменные... Поиск нужных функций через WinApi (Microsoft Visual Studio\COMMON\Tools\Winapi). Сложно по началу, но используются рационально ресурсы, основные ДЛЛ всегда с ОС, в регистрации не нуждаются.

И не только WinApi можно использовать, но и любую ДЛЛ главное, что б была Вывод написание (на С/С++) ОСХ в случаи персонально спец функции своей проги, ДЛЛ если этими функциями заинтересуются ещё сторонние. Использование по мере доступности в одной из форм (ОСХ/ДЛЛ).

К сожалению, зарегить не получается, а внешних tlb файлов к ним не прилагается. regsvr32 выдаёт следующую ошибку:
Значит ли это, что в данном файле находится com-компонент или, наоборот, не находится? Так, например, для всех прочих dll-файлов выдаёт отличное сообщение:
АctiveXplorer их не открывает. Как можно узнать, какие объекты находятся в dll-файле (нужны их имена для вызова в случае, если удастся зарегить)?

Вообще, всегда ненавидел подобные майкрософтские задрючки, но производители девайса вдруг посчитали, что com-технология проще в использовании, чем обычные dll-ки. Теперь вот приходится разбираться что к чему.

Ситуация немного изменилась. Нашелся dll-файл, который был зарегин в системе и com-объект был подключён, однако для работы железа этого оказалось недостаточно (object выдаёт неизвестную ошибку).
Поэтому вопрос, может кто знает, как по бинарному содержимому файла dll определить, какие ещё дополнительные dll-библиотеки (с дровами) нужны для нормальной его работы и в какой каталог эти библиотеки надо закидывать. Пишу эти идиотские вопросы, потому что ранее с dll дела не имел и не собирался иметь, даже не знаю, для чего они нужны. -)

Но хачу вам всем сказать что эти функций этой програмы можит быть недаступна :) смотря какая у вас система на компе, чтобы С++ но я делал через прогу Autoit3 Я писал сам скрипт что бы он выполнял команды. вот и всё

zl3p, Зависимости dll можно посмотреть с помощью PE Explorer или подобных программ. Но это не спасёт, если ддка подгружается динамически (чего, правда как правило не делают). И в случае зависимостей от дров тоже не поможет: драйверы (настоящие - системные) используются с помощью посредника в виде апи операционной системы, которое в системе присутствует всегда, но железку тем не менее вполне может не видеть.

В какой момент? В момент создания ком-объекта, или уже при использовании?

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

при использовании.
Наверное, я предполагаю, что дело в том, что я не могу выполнить файл "Pluginps.mk", т.е. получить нужный мне dll proxy/stub.
Короче, я понял, какой плохой этот Visual Studio. В нём ничего не возможно скомпилировать до конца, чтоб не выдало ошибок. Причём, заметься, код НЕ Я писал.

Вот, например, [начиная разбираться с самого начала] составил, как в примере по COM, файл server.idl:
Начнём с того, что программа midl из текущей дириктории не доступна (правильно, ведь это вам не линукс). Но даже если указать полный пусть, типа "F:\BC5\SDKTOOLS\midl.Exe" server.idl, то всё заканчивается ошибкой:
и меня это уже начало раздражать...