Re: HRESULT only required for Automation-compatible interfaces?

On Fri, 07 Dec 2007 23:05:33 +0200, Igor Tandetnik <itandetnik@mvps.org>=
  =

wrote:


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 datatyp=
es =

MIDL doesn't like (because it doesn't know them). Here's an example:

[local, ...]
__interface IBarLocal
{
   std::string GetString();
};

When MIDL tries to parse the IDL file it obviously complains about =

std::string. And putting the whole definition of std::string into the ID=
L =

file is a bit difficult. :)

I must do something wrong or look for the solution in the wrong place. T=
he =

basic problem I have is that my COM classes which implement a lot of =

interfaces for "public use" have to exchange some more data which might =
 =

not be Automation-compatible.

Imagine a method like this:

STDMETHODIMP Foo::DoSomething(IBar *bar)
{
   // IBar is a public interface which is meant to be used by customers =
of =

the library.
   // In order for Foo::DoSomething() to work data in IBar must be acces=
sed =

which must be
   // there for IBar to work but which is not meant to be seen by custom=
ers =

of the library.
   // As Foo needs to access some hidden data now I thought of implement=
ing =

another (maybe
   // local?) interface IBarLocal:
   IBarLocal *barlocal;
   HRESULT hr = bar->QueryInterface(&barlocal);
   ...

   // Now barlocal refers to a COM interface which doesn't need to be =

Automation-compatible
   // as it's only for internal use. The idea is now to access any =

C++ stuff directly (std::string
   // is only an example as this one could be easily converted to BSTR o=
f =

course):
   std::string s = barlocal->GetString();
   ...
}

What I wonder now is: How should IBarLocal ideally be defined? Or is the=
re =

anything wrong in the way I proceed?

Boris