Доступ к Windows контактам (до Win10) из JScript (или любого ActiveScripting) - PullRequest
0 голосов
/ 16 февраля 2020

Я хочу использовать COM-объект с progID Windows.Contact.1 через ActiveScripting (JScript, VBScript, Python, et c).

Этот COM находится в C:\Program Files (x86)\Common Files\System\wab32.dll. Кажется, для него нет TypeLib. COM предоставляет, среди прочего, IContact для "Windows Адресная книга" (хранение контактов в виде XML в папках, как в Windows 7). IContact документирован здесь .

В JScript я сделал:

var co = new ActiveXObject("Windows.Contact.1");
typeof co;  // results in: unknown

Так как это приводит к unknown, у меня есть подозрение, что этот COM не может быть пригодный для сценариев. Где-то я читал, что все, что наследуется от IUnknown, не может быть использовано для написания сценариев, вместо этого оно должно наследоваться от IDispatch. Но я не уверен относительно того, насколько это действительно, и есть ли обходные пути.

Я хотел бы попросить подтверждения моих подозрений (поскольку я новичок во всем этом и у меня нет C ++ или C# background) или узнать, как использовать Windows.Contact.1 из сценариев, в том числе узнать, какие методы / объекты я могу использовать, не прибегая к TypeLib.

У меня есть доступ к таким страницам, как Программирование Windows Контакты и связанные с ними, но сначала мне нужно получить экземпляр в ActiveScript (подойдет JScript, VBScript, Python, Lua). У меня также есть доступ к приложениям, таким как «MS OLE View» и «OLEView Do tNet» . Спасибо.

1 Ответ

1 голос
/ 18 февраля 2020

Есть целые книги на эту тему, но вот очень упрощенная история. Существуют в основном 3 «категории» COM-интерфейсов:

Интерфейсы, производные от псевдонимов IUnknown

  • для программирования: раннее связывание, (пользовательское) связывание с vtable
  • самый простой способ реализовать COM "сервер"
  • это всего лишь двоичный контракт (расположение методов, сигнатура метода, параметры поведения, такие как вход / выход для поддержки нескольких квартир / процессов,. ..)
  • вам нужно каким-то образом сообщить своим абонентам, что это за бинарный контракт, который вы поддерживаете (вы можете использовать .idl, .tlb или что угодно , что ваш абонент может понять)
  • Есть несколько официальных способов документирования ваших интерфейсов, производных от IUnknown: .idl -> .h и .tlb - самый стандартный
  • , поддерживаемый только определенным классом языков (например, C / C ++, . NET, Delphi), те, кто понимает .tlb (или .idl, или эквивалентный .h), или те, кто позволяет переопределить макет вручную (например, NET). Вы можете прекрасно определить язык, который может это сделать без использования .tlb. В этом прелесть COM, это просто бинарный контракт.
  • если ваш язык не поддерживает его, вы просто не сможете его использовать, вам придется написать или использовать оболочку с языком, который поддерживает это и выставляет это способом, которым поддерживает Ваш язык. Например, Powershell не поддерживает IUnknown-derived интерфейсы (я не уверен на 100%), но поддерживает. NET, поэтому он может использовать. NET в качестве "супероболочки".

IDispatch interface

  • требуется только одна IUnknown хорошо известная реализация интерфейса: IDispatch
  • псевдонимов для программирования: позднее связывание, автоматизация OLE, автоматизация COM или просто Автоматизация (не путать с UI Automation)
  • изобретена для языков более высокого уровня (сначала VB / VBA, чуть позже ActiveScripting)
  • поддерживается только определенным классом языка, и способ его поддерживаемый варьируется (например, он поддерживается в C ++, конечно, но это не супер просто без оболочек или инструментов, как директива Visual Studio C ++ #import). JScript и VBScript не совсем поддерживают один и тот же набор функций в отношении автоматизации.
  • вы должны использовать только предопределенный список типов " Типы, совместимые с автоматизацией * ":
  • эти типы изначально очень связаны с VB / VBA (VARIANT, SAFEARRAY, BSTR, что означает "Basi c String" ...)
  • с более высокого уровня язык, он действительно делает COM намного прозрачнее и проще, как это и было в этом (и может усложнить работу с более низкими уровнями ...), он также допускает тонкости «syntacti c sugar»
  • note реализация IDispatch может быть очень динамичной c и действительно с поздней привязкой во время выполнения (получить идентификатор имени -> invoke), но большинство доступных инструментов программирования вполне замораживает список идентификаторов / имен во время компиляции (например:. * 1087) *) потому что они поддерживают Dual интерфейсы.

Dual интерфейсы:

  • интерфейсы, которые реализуют пользовательский интерфейс IDispatch-derived и реализуют сам IDispatch для соответствия пользовательский интерфейс (оба я якобы, конечно, «эквивалентные»). Взгляните на ссылку ниже, там есть красивые изображения.
  • из-за IDispatch, вы должны использовать только типы данных, совместимые с Automation в IDispatch -приобретенном методе.
  • это больше работы для реализации (так как обычно это делается с помощью инструментов программирования, например: ATL)
  • немного проще для нативных (C / C ++, et c.) вызывающих (не нужно использовать IDispatch обертки), но вам все еще нужно переварить типы данных автоматизации

ИМХО, одно из лучших одностраничных введений в COM здесь: Введение в COM

...