О соглашении о вызве

← →
Сергей М. © (2010-01-29 19:22) [0]

В некоем VBA-модуле мной предполагается декларация внешней моей ф-ции из моей библ-ки и соответствующий ее вызов:

Declare Sub "GetSomeAutoObject" ... Lib "MyDelphiLib.DLL" ... As Object
..
Dim SomeObject As Object
Set SomeObject = GetSomeAutoObject

Предполагаю что соответствующая экспортируемая мной ф-ция GetSomeAutoObject в моём модуле MyDelphiLib.DLL должна быть объявлена мной как

function GetSomeAutoObject(var obj): HResult; stdcall; // safecall convention

Попытка вызова этой эксп.ф-ции из моего же дельфийского приложения успешен.

Попытка ее же вызова в вышеприведенном VBA-коде приводит к краху вызывающего приложения.

Понимаю что проблема - в правильном сопряжении на уровне соглашения о вызове.

На какие я грабли наступил ?

← →
Дмитрий С © (2010-01-29 19:36) [1]

Могу ошибаться, но судя по примерам из сети в delphi функцию нужно объявить так:

function GetSomeAutoObject: OleVariant; stdcall;

← →
Ганя (2010-01-29 19:46) [2]

> Дмитрий С © (29.01.10 19:36) [1]

Тогда уж наверно
function GetSomeAutoObject: OleVariant; safecall;

← →
Дмитрий С © (2010-01-29 19:53) [3]

> Ганя (29.01.10 19:46) [2]

Именно stdcall.

safecall - это из COM-а, а он тут не причем. В тех же примерах из сети аналогичным образом вызываются функции, например, из kernel32.dll, а уж там они точно stdcall.

← →
Сергей М. © (2010-01-29 19:56) [4]

Увы, не работает.
С тем же результатом - крахом вызывающего VBA-приложения.

← →
Дмитрий С © (2010-01-29 20:16) [5]

> Сергей М. © (29.01.10 19:56) [4]

Специально для тебя набросал пример, который работает. (проверил в VBA екселя).

В Excel:

Private Declare Function GetMyObject Lib "C:\Users\Dima\Documents\RAD Studio\Projects\TestVBACall\TestVBACall.dll" () As Variant Sub Test() Dim MyObj Set MyObj = GetMyObject MyObj.Test ("Привет") End Sub

В Delphi:

library TestVBACall; uses Windows, ObjComAuto; {$METHODINFO ON} type TTestObject=class procedure Test(S: String); end; { TTestObject } procedure TTestObject.Test; begin MessageBox(GetActiveWindow, PChar(S), "Test", 0); end; function GetMyObject: OleVariant; stdcall; begin Result := TObjectDispatch.Create(TTestObject.Create, True) as IDispatch; end; exports GetMyObject; begin end.

Я думаю ошибка была в типе возвращаемого значения у тебя.

← →
Сергей М. © (2010-01-29 20:37) [6]

> Дмитрий С © (29.01.10 20:16) [5]

Private Declare Function ... As Variant Sub Test() Dim MyObj Set MyObj = GetMyObject End Sub

при запусе Test() Access2000 VBA на эту конструкцию заявляет : Run-time error 13 : Type mismatch

← →
Дмитрий С © (2010-01-29 20:43) [7]

> Сергей М. © (29.01.10 20:37) [6]

Именно на эту?

Где б взять Access 2000, проверить.

← →
Дмитрий С © (2010-01-29 20:45) [8]

P.S. Я проверял в 2007 Excel-е и Access-e.

← →
Сергей М. © (2010-01-29 21:34) [9]

> Дмитрий С © (29.01.10 20:43) [7]
> Именно на эту?

Именно на эту.

> Дмитрий С

Итак эта беда

Declare Function ... As Variant Sub Test() Dim MyObj As Object Set MyObj = GetMyObject End Sub

заработала.

Однако она не решает вопроса с передачей в вызывающий VBA-код OLE-исключений, которые может возбудить вызываемый при, например, невозможности по каким-либо причинам вернуть диспинтерфейс запрошенного объекта

Я немного полазил по MSDN пытаясь найти примеры и информацию по взаимодействию C++ и VBA - нет ее, что в очередной раз подтведило слухи, что МС убил/убивает C++
Вот по С# очень много информации и даже подчеркнуто, что передачас строк в VBA не представляет проблемы в отличии от С++, поскольку используется прямой синтаксис в VBA S as string или как там в С# объявляются строки в параметрах.

> Дмитрий С © (31.01.10 07:51) [11]

> Что мешает использовать нормальный Ole (т.е. COM)?

Мне - ничто.
А можно ли хотя бы в общих чертах, в чем, по твоему имху, заключается "нормальный olle (т.е. COM)" ?

О соглашении о вызве Найти похожие ветки