Вопрос по функции _comQueryInterface

[Peter]

К сожалению не нашел описание функций серии _comXXX, поэтому есть вопросы.
Я воспользовался утилитой AtlTLB, которая сгенерировала врапер интересующего объекта.
Получившийся файл содержит вызовы двух функций _comCreateInstance и _comQueryInterface у которых в качестве аргументов используются GUID-ы (объекта и интерфейса).
Вопрос: как избавиться от идентификации объекта и интерфейса с помощью GUID-ов? Дело в том, что разработчик объекта периодически вносит изменения в интерфейс (добавляет функции), соответственно меняется GUID интерфейса (старый интерфейс удаляется). Таким образом, мне придется каждый раз менять во врапере GUID интерфейса, что не есть нормально для языка высокого уровня. Хотелось бы как, например в VB, обращаться к объекту по имени и использовать интерфейс с атрибутом [default].
Методом научного тыка доказано, что функция _comCreateInstance способна вместо GUID-а использовать имя объекта. Остается вопрос, как заставить _comQueryInterface вернуть интерфейс с атрибутом [default], при этом каким у него будет GUID не важно?

[Peter]

Похоже все специалисты в отпуске

[cruger]

Вкратце:
1 Это есть нормально для языка высокого уровня
2 Это есть нормально для com вообще

Резюме: никак

Кстати, функции _comXXX внутренние, и не подлежат документированию

[Peter]

Для com вообще это действительно нормально, а вот для языка высокого уровня нормально скрывать такие детали реализации com как GUID (VB, Java,..).

Резюме: засада, придется маяться.

P.S. Может можно все-таки что-то придумать (доработать) чтобы сделать работу с com из Галактики более удобной. Я сейчас пользуюсь AtlTLB, в целом все устраивает (хотя язык высокого уровня мог бы генерировать врапер автоматически в момент компиляции), если не считать выше описанной проблемы.

[cruger]

А никакой разницы между генерацией вручную и генерацией в момент компиляции нет. Точно так же при установке другой версии объекта ничего работать не будет.

Тут поможет только генерация в момент выполнения. Что нормально для скриптовых языков, типа VB. Скриптовых, а не высокого уровня.

Что касается Java, то разве там языке есть что-то для com? Афаик там для интеграции с com существуют лишь сторонние независимые библиотеки, которые не предоставляют возможности объектной работы с com-объектом.
Например, j-Interop - http://www.j-interop.org/sampleusage.html или JACOB -

Код: Выделить всё

		ComThread.InitSTA();

		ActiveXComponent xl = new ActiveXComponent("Excel.Application");
		try {
			System.out.println("version=" + xl.getProperty("Version"));
			System.out.println("version=" + Dispatch.get(xl, "Version"));
			Dispatch.put(xl, "Visible", new Variant(true));
			Dispatch workbooks = xl.getProperty("Workbooks").toDispatch();
			Dispatch workbook = Dispatch.get(workbooks, "Add").toDispatch();
			Dispatch sheet = Dispatch.get(workbook, "ActiveSheet").toDispatch();
			Dispatch a1 = Dispatch.invoke(sheet, "Range", Dispatch.Get,
					new Object[] { "A1" }, new int[1]).toDispatch();
			Dispatch a2 = Dispatch.invoke(sheet, "Range", Dispatch.Get,
					new Object[] { "A2" }, new int[1]).toDispatch();
			Dispatch.put(a1, "Value", "123.456");
			Dispatch.put(a2, "Formula", "=A1*2");
			System.out.println("a1 from excel:" + Dispatch.get(a1, "Value"));
			System.out.println("a2 from excel:" + Dispatch.get(a2, "Value"));
			Variant f = new Variant(false);
			Dispatch.call(workbook, "Close", f);
		} catch (Exception e) {
			e.printStackTrace();
		} finally {
			xl.invoke("Quit", new Variant[] {});
			ComThread.Release();
		}

[Peter]

В этом как раз и была идея. Во время исполнения получить интерфейс с атрибутом [default] и далее работать с ним в надежде, что используемые в программе методы существуют в полученном интерфейсе (если нет, генерируется соответствующее исключение). Для этого ничего менять не надо, необходимо только добавить такую возможность. Такая схема работы позволила бы приблизиться по удобству работы с com к VB.

Что касается AtlTLB, то для меня генерирование врапера до компиляции как раз плюс (врапер можно скомпилировать отдельно, врапер можно подправить, например, удалить лишнее). Но если не искушённый человек просто хочет использовать com-компонент в своей программе, то нельзя сказать что AtlTLB это удобно (для него это лишний шаг, да и много ли людей знают про AtlTLB). Таким образом, AtlTLB это хорошо, но возможность обойтись без нее открыла бы дорогу к использованию com в Галактике гораздо большему количеству людей на местах.

[cruger]

Вся идея была в том, что б работать с компилятором как с интерпретатором? Хитро́
Однако ж у нас компилятор.
VB, кстати, работает по сути не с com.

[Peter]

Если нет возможности, значит ничего не поделаеш .