"Simon" <si****************@btinternet.please.com> wrote in message
news:c4**********@hercules.btinternet.com...
<snipped />
The return of an automation interface method is limited to HResult in
Delphi, I don't know why.
I have no problem getting and setting properties and I have no problem
calling methods. The issue is getting a return (out) parameter from the
method.
eg. Method = AddText(in Text: BSTR; out Index: long * )
I can call the above method and it will execute, but I cannot get the out
parameter.
In Delphi the out parameters must be pointer types.
Any ideas?
Let's clear up a couple of things first...
The HRESULT return type of an automation interface does not have
anything to do with your parameters of return value, but is the result
of the automation process (ie. success/error code).
The Delphi help file say that:
"If a parameter type is specified as a Pointer type, the Type Library
editor usually translates that type into a variable parameter. When the
type library is saved, the variable parameter's associated ElemDesc's
IDL flags are marked IDL_FIN or IDL_FOUT."
// ---------- copied from Delphi help...----------------
DevGuide: Developing COM-based applications
Valid types
Topic Groups See Also
In the Type Library editor, you use different type identifiers, depending on
whether you are working in IDL or Delphi. Specify the language you want to
use in the Environment options dialog.
The following types are valid in a type library for COM development. The
Automation compatible column specifies whether the type can be used by an
interface that has its Automation or Dispinterface flag checked. These are
the types that COM can marshal via the type library automatically.
Delphi type IDL type variant type Automation compatible Description
Smallint short VT_I2 Yes 2-byte signed integer
Integer long VT_I4 Yes 4-byte signed integer
Single single VT_R4 Yes 4-byte real
Double double VT_R8 Yes 8-byte real
Currency CURRENCY VT_CY Yes currency
TDateTime DATE VT_DATE Yes date
WideString BSTR VT_BSTR Yes binary string
IDispatch IDispatch VT_DISPATCH Yes pointer to IDispatch interface
SCODE SCODE VT_ERROR Yes Ole Error Code
WordBool VARIANT_BOOL VT_BOOL Yes True = -1, False = 0
OleVariant VARIANT VT_VARIANT Yes Ole Variant
IUnknown IUnknown VT_UNKNOWN Yes pointer to IUnknown interface
Shortint byte VT_I1 No 1 byte signed integer
Byte unsigned char VT_UI1 Yes 1 byte unsigned integer
Word unsigned short VT_UI2 Yes* 2 byte unsigned integer
LongWord unsigned long VT_UI4 Yes* 4 byte unsigned integer
Int64 __int64 VT_I8 No 8 byte signed integer
Largeuint uint64 VT_UI8 No 8 byte unsigned integer
SYSINT int VT_INT Yes* system dependent integer (Win32=Integer)
SYSUINT unsigned int VT_UINT Yes* system dependent unsigned integer
HResult HRESULT VT_HRESULT No 32 bit error code
Pointer VT_PTR -> VT_VOID No untyped pointer
SafeArray SAFEARRAY VT_SAFEARRAY No OLE Safe Array
PChar LPSTR VT_LPSTR No pointer to Char
PWideChar LPWSTR VT_LPWSTR No pointer to WideChar
* Word, LongWord, SYSINT, and SYSUINT may be Automation-compatible with some
applications.
See safe arrays for more information about the SAFEARRAY Variant type.
Note
The Byte (VT_UI1) is Automation-compatible, but is not allowed in a Variant
or OleVariant since many Automation servers do not handle this value
correctly.
Besides these IDL types, any interfaces and types defined in the library or
defined in referenced libraries can be used in a type library definition.
The Type Library editor stores type information in the generated type
library (.TLB) file in binary form.
If a parameter type is specified as a Pointer type, the Type Library editor
usually translates that type into a variable parameter. When the type
library is saved, the variable parameter's associated ElemDesc's IDL flags
are marked IDL_FIN or IDL_FOUT.
Often, ElemDesc IDL flags are not marked by IDL_FIN or IDL_FOUT when the
type is preceded with a Pointer. Or, in the case of dispinterfaces, IDL
flags are not typically used. In these cases, you may see a comment next to
the variable identifier such as {IDL_None} or {IDL_In}. These comments are
used when saving a type library to correctly mark the IDL flags.
--
Dag.