COM interfaces generated from COBIA IDL

[jasper]

It turns out that the standard marshaler does not work with any interface that is derived from IUnknown unless it is explicitly marked with the oleautomation keyword.

In order to be able to use the standard marshaler, I suggest we remain compliant with this.

I suggest the following modifications to the current implementation:

• I suggest we mark all IUnknown derived interfaces produced from COBIA IDL to COM IDL conversion as 'oleautomation' in order to be able to use the standard marshaler,
• I suggest we comply to the documentation on that, and do not use GUID as an argument type. It very rarely happens that this is an actual argument in any interface of use, so I suggest when marshaled to COM we pass it in string representation with the BSTR argument type

In addition,

• the SAFEARRAY arguments are all 'oleautomation' - do we stick to converting ICapeArrayReal, ICapeArrayInteger, ...., to VARIANT? Or shall we marshal these as SAFEARRAY of the appropriate type in the future?

• currently, enum values are converted to IDL type long. In addition, the enum is in the IDL. We could convert the function signatures to the enum definitions, which would be nicer, but the COM documentation is not clear about the size of the enum value. Do we use long? Or the enum definition?

[jasper]

Note: marking interfaces with 'oleautomation' also makes that RegisterTypeLib/UnRegisterTypeLib? perform the interface registration, which is not the case without this annotation.

[jasper]

Commit [5597e84198f763cef95606a1032d1e09df0d8b64] adds 'oleautomation' to the generated COM IDL

Commit [565ccc1daa6c066fcc702b8db8cdda77904a7339] changes COM marshaling of CapeUUID to BSTR instead of GUID* so that the interfaces are oleautomation compliant. COM Test PMC, COM Test code, COM marshaling, COM proxy code generation are adapted accordingly.

[jasper]

This link

[url]​https://learn.microsoft.com/en-us/windows/win32/midl/oleautomation

lists the types compliant with the oleautomation annotation.

[jasper]

M&T SIG meeting (Jasper+Michael):

1. we stick with oleautomation - unless Michael finds something better
2. if we stick with oleautomation, we marshal CapeUUID as BSTR and not as REFGUID which is incompatible with the oleautomation attribute
3. no strong preference for SafeArray? vs VARIANT
   • SAFEARRAY is less pleaseant to look at and to automatically clean up in many programming languages - this is a pro for VARIANT
   • SAFEARRAY is stronger typed, this is a pro for SAFEARRAY
   • Michael has no strong preference
   • Jasper mildly prefers VARIANT over SAFEARRAY arguments
4. For enum the suggested solution is to mark all enums as v1_enum as here [url]​https://learn.microsoft.com/en-us/cpp/windows/attributes/v1-enum?view=msvc-170&viewFallbackFrom=vs-2017[/url], then use strong enum typing, and 32-sized value marshaling. Without this flag, the size of enum is system dependent and unknown to COBIA which makes marshaling hard [url]​https://learn.microsoft.com/en-us/windows/win32/midl/enum[/url]

for (1) and (2) no changes are needed. If (3) is VARIANT, no changed are needed.

(4) needs implementation as currently enum is typed as LONG (which is equivalent but uglier than the suggested solution)

[jasper]

Decisions (M&T SIG June 25 2024):

3. keep VARIANT for array types instead of SAFEARRAY

4. use v1_enum and use the enum type in the function signatures

[jasper]

fixed in commit 4de384ca63d4beac03099342262f8588d22c0b3d