Re: HRESULT only required for Automation-compatible interfaces?

"Boris" <boris@xxxxxxxxxxx> wrote in message
news:op.t2zqpgfq45fww6@xxxxxxxxxxxxxxx
Igor, I've been playing around with [local] but didn't get far. The
problem is that when I create a [local] interface which is neither
Automation-compatible nor cares about marshalling I end up using
datatypes MIDL doesn't like (because it doesn't know them).

Even in a [local] interface, you are still limited to MIDL types (note
that not all types MIDL supports are automation-compatible).

Here's an
example:
[local, ...]
__interface IBarLocal
{
std::string GetString();
};

You seem to be using ATL attributes. Don't do that - they are buggy.
Redo your project as non-attributed.

You don't have to define your interfaces in IDL. You can just hand-craft
an .h file. At the end of the day, an interface is just a C++ class with
no data members and all methods pure virtual. IDL is primarily useful
for generating marshalling support - but you explicitly don't want it.

Now, an interface using C++ classes (such as std::string) is rather
ill-advised. You are not really doing COM anymore (though you can get
away with it under certain restrictions). For example, if the COM object
implementing this interface is in a DLL, and the client in an EXE, the
two must be compiled by the same version of the same compiler and linked
to the same flavor of CRT DLL (otherwise, binary layout of the string
class could be different in the two modules, and/or memory allocated in
one module could not be freed in the other). This kind of defeats the
point of COM.

MIDL-compatible data types are there for a reason: they have
well-defined binary layout and memory management protocol associated
with them. COM, being a binary standard, relies on both.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925


.

Relevant Pages

  • Re: SAFEARRAY(Interface)
    ... This method definition is clearly not automation-compliant. ... So it means that a custom proxy-stub must be generated by the MIDL ... Out of the box, if you try to define the above COM interface method, the MIDL compiler give a warning message: ... If so, I'm speculating that this COM object's interface was designed not to be marshaled at all, and therefore the COM ...
    (microsoft.public.win32.programmer.ole)
  • Re: IDL to C#?
    ... but many attributes used in the oleidl.idl cant be parsed be ... > MIDL and TlbImp is the way to go. ... > interface declarations directly in C# instead. ...
    (microsoft.public.dotnet.languages.csharp)
  • Benutzung von Datentypen aus COM-Dlls
    ... Unser Kunde hat eine Typenbiliotek von der ich ... Wenn ich aber das Interface als parameter meiner Methode einbaue Gibts ... Kann mir jemand auf die Sprünge helfen damit der MIDL nicht mehr streikt? ... Next by Date: ...
    (microsoft.public.de.vc)
  • Re: MIDL class an C++Code binden
    ... MR - Rudolf Meier ... "Matthias Friedrich" schrieb im Newsbeitrag ... ich habe in MIDL ein Interface deklariert und eine Klasse, ...
    (microsoft.public.de.vc)
  • Re: In-process cross-thread (cross-apartment) marshaling
    ... you register the interface marshaling code.) ... object (ask for IUnknown with the IID of your interfrace as the ... Marshalling an IUnknown and unmarshalling an IUnknown is successful, ...
    (microsoft.public.win32.programmer.ole)
Loading