Ошибка "Interface not supported"

← →
LeS (2002-08-05 14:18) [0]

Уважаемые мастера. Вы не знакомы с этой ошибкой, почему и как?
Один ком "общается" с другим комом в сети. Сервера зарегистрированы, права розданы в dcomcnfg. При попытке обращения к методу кома на другом компе возникает эта ошибка. Вызов с XP на 2000-ный, ошибка на XP. Заранее, спасибо.

← →
А. Н. Оним (2002-08-05 17:13) [1]

Не помню точно, но кажется именно такая ошибка вылезает в следующей ситуации: идёт использование не Ole-совместимых (Oleautomation) интерфейсов и прокси отсутствует у клиента. То есть клиент достукивается до IUnknown, а вот перейти к другому уже и впрямь не может - нет нужного прокси. Правда, это маловероятно, так как состряпать подобный интерфейс в Delphi мне не удавалось. Поэтому вероятней другое.
Ты создал интерфейс, но снял со вкладки OleAutomation галочку.
Теперь после регистрации сервера, насколько я заметил, вкладка в реестре с интерфейсом вообще не появляется в разделе HKEY_CLASSES_ROOT\Interface\{IID}... И при обращении между аппартаментами или процессами, то есть в тот момент, когда необходимо создание прокси для клиента и стаба для сервера
SCM не знает, откуда взять нужную прокси/стаб DLL. Всё, что в таком случае необходимо, это поставить галочку, обновить TypeLib и перерегистрировать сервак. Теперь при регистрации интерфейс будет появляться в реестре и сообщать о своём классе стаба.
HKEY_CLASS_ROOT\Interface\{IID}\ProxyStubCLSID32
По этому классу SCM будет грузить сервер с реализацией и всё заработает.
Любопытно, Delphi не позволяет строить неOle-совместимые интерфейсы, но позволяет метить их как неOle-совместимые. Зачем? Дело в том, что в Delphi может идти разработка сервера, который и в действительности реализует неOle-совместимые интерфейсы. Для этого можно например импортнуть чужой TypeLib, где такие интерфейсы водятся, затем создать наследника от такого интерфейса, а ProxyStub Dll позаимствовать со стороны. Совсем недавно мне пришлось именно так и поступить.

← →
LeS (2002-08-06 13:47) [2]

Добрый день\утро\ночь А. Н. Оним.
Действительно, делфя позволяет строить не OleAutomation. Но, к сожалению,галочка поставлена.

← →
А. Н. Оним (2002-08-06 15:32) [3]

Я нашёл ещё несколько глупых, но очень действенных способов создания подобной ошибки: не сочти за издевательство, но сейчас я расскажу как этого добиться даже в "тепличных" условиях:
Итак, мы создали Application, добавили в него COM объект, описали интерфейс, сгенерили реализацию методов, убедились, что интерфейс помечен как OleAutomation. Зарегестрировали сервер MyServer.exe /RegServer. Пусть модуль с коклассом реализован примерно так:

uses
Windows, ActiveX, ... MyServer_TLB; // библиотека типов на PAS
type
TTest = class(TTypeComObject, IMyInterface)
protected
function MyFunction(...): HResult ...
end;

Способ 1:
Удалить из списка наследования интефейс IMyInterface. Все его методы теперь станут родными методами класса TTest и компилятор для сервера даже не обругнётся. А вот клиент эту разницу ощутит ;)

Способ 2:
После создания сервера дать клиенту файл MyServer_TLB, затем подумать о каких-нибудь новшествах в сервере, удалить из TypeLib сервера интерфейс MyInterface, затем, спохватившись, его заново набить (и получить новый IID) и долго безуспешно пытаться соединить клиента с сервером по старому IID.

Это всё глупости, конечно, но кто знает? А вообще убедись, что интерфейс сервера зарегестрирован на клиенте. Пошарь в реестре клиента вкладку HKEY_CLASSES_ROOT\Interface и если не найдёшь интересующий клиента IID то всё понятно. Такой ситуации можно добиться например так (даже совсем не нарочно):
Сервер разрабатывался на одной станции, а клиент на другой. Для разработки клиента я просто перетащил отображение TypeLib сервера на PAS и подцепил его в клиентский проект. Теперь зарегестрировал сервер и пытаюсь (безуспешно) дотянуться до его интерфейсов с клиента. А интерфейсы сервера на клиенте и не зарегестрированы... И откуда брать клиенту прокси (даже если это стандартный прокси для интерфейсов OleAutomation) тоже не ясно.
Я бы делал так:
1. Гляжу клиентский реестр в поиске нужного клиенту интерфейса
Если его там нет, то регистрирую сервер на клиенте (потом пытаюсь удалить сервер физически - никогда так не делал, обычно оставлял)
2. Интерфейс есть, но ничего не работает. Тащу сервер на клиента и смотрю на одной машине.

← →
LeS (2002-08-06 15:49) [4]

Спасибо за "А вообще убедись, что интерфейс сервера зарегестрирован на клиенте":)..ошибки нет, тока терь клиент виснет..кошмар:) наверно, опять чтото намудрил...

← →
А. Н. Оним (2002-08-06 16:38) [5]

Так в этом было дело?
Повисание дело обычное, если работаешь с потоками и мудришь с аппартаментами. У тебя что-то многопоточное? Получил, наверное обычный deadlock. При повисании и прочих непонятных ошибках на вызове я всегда проверяю, дошёл ли вызов до сервера или нет. И ушёл ли с него.
На самом деле, (это только моё мнение), в качестве учебной среды выбирать delphi для изучения Com не стоит. Дело не только в том, что большинство книжек по COM, которые я видел, аппелируют к MSVC, а книги по Delphi рассматривают это слишком верхоглядно и дают слабые теоретические основы, но в том, что Delphi настолько круто инкапсулирует работу с COM в своих классах (а те настолько круто привязаны к TypeLib"у проекта), что у меня часто возникало ощущение - "меня водят за нос". Особенно становится весело, когда приходится в Delphi реализовывать что-то непредвиденное и в литературе по delphi не описанное. Например принимание Sink"ов сервером, интерфейсы которых не описаны в TypeLib"е проекта. Я потратил часа 3, а то и все 5, разглядывая то, насколько Delphi круто дурачит меня своими классами.
Реккомендую MSVC или C++ Builder. Кажется, ATL у них один и тот же. Из книг для начала - Дональда Бокса "Сущность технологии COM" (как чисто теоретическую), Трельсена "COM и ATL 3.0" (как прикладную, нет хорошей теории, нет хорошей практики, но применение ATL действительно разобрано, хотя и на простых примерах, а главное - многи примеры создаются с нуля, безо всяких Wizard"ов)... Удачи!

← →
LeS (2002-08-06 17:07) [6]

Спасибо за совет. Действительно, дока нормального для "учеников" по этому делу не находил, и не найду наверно, и то что в делфях много пантов а толку мало (как я понял из твоего мнения) - согласен. Всё что у меня есть - это демки по этой теме:) + хорошее знание delphi и опыт в рамках создания приложении не по этой теме:)...

Всего хорошего!..

← →
А. Н. Оним (2002-08-06 17:26) [7]

Да нет, не в понтах никаких дело. Вообще не понятно, что значит среда понтовая и не понтовая? Критерий понтовости для среды разработки представить сложно.
Мне приходилось разрабатывать сервера в MSVC и в Delphi, и Delphi как средство разработки мне сейчас нравится куда больше (симпатии выражаю и Builder"у), нежели MSVC.
Что особенно радует в Delphi, так это скорость разработки, работа со строками и отсутствие (вернее, меньшее наличие) возможностей насажать лики, т.е. утечки памяти. Бонусы визуального программирования с VCL также имеют свой вес в моих глазах против MSVC/MFC. Безусловно, smart pointer"ы в C++ и шаблоны ATL помогают избавиться от "глупостей" невинимательности, но в Delphi это всё куда лаконичней. Однако, за лаконичность стоит расплачиваться непонятной реализацией этой самой лаконичности, а отсутствие литературы только всё усугубляет. Программист уподобляется волшебнику, который тыкнет там и здесь и всё по-волшебству заработает. Хорошо, если такой "волшебник" был когда-то хорошим подмастерьем со стажем, но если подмастерью дать волшебную палочку то всё выйдет как в песни Аллы Пугачёвой "сделать хотел грозу, а получил козу". Но это всё лирика.

Ошибка "Interface not supported" Найти похожие ветки