Re: COM question

Thanks, Werner. I read your article and it's a keeper, absolutely. At this
point, I'm having problems even getting a DLL-based object with no
IEnumString or other weird types involved to be launched on the CE device
via DCOM from another machine. I'm just trying, now, to prove that CE3 can
be the server! DCOM with the client on the CE device works fine, so DCOM is
in the build, but no luck getting DllHost (I presume), to grab my server
when my PC asks for it (just get the usual class not registered).

This is actually an OLE for Process Control (or they've probably dropped the
OLE thing and just call it OPC, now), application. They're working on a new
communication architecture for the post-DCOM days but I'd just like to get
this working before too much time goes by.

Thanks for the reply and for all of the tips!
Paul T.

"Werner" <Werner@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:0069567F-57DA-4762-AACD-9D55DAD7D761@xxxxxxxxxxxxxxxx
Hi Paul,

This is a good question! As John already explained, Windows CE doesn't
have
the automation marshaller (the dll that makes sure that all OLE automation
compatible datatypes are marshalled across the wire automagically without
the
need for a proxy/stub DLL, eg BSTR, VARIANT, LONG, IUnknown, ... Or in
other
words the types you can use in VB6 or VB6 scripting)
Because the automation marshaller is not available on the CE side, you
have
to provide a proxy/stub DLL for IEnumString yourself. How do you do that?
Well we need to hack a bit into some IDL files, but I'll show you how to
do
it. I did it once for IEnumVariant, so I know it works.

1. First look in objidl.idl for IEnumString (IEnumVariant is in oaidl.idl
which includes objidl.idl) Copy/paste the interface definition and place
it
in a seperate file (eg IEnumString.idl)
2. Next you need to try to compile this IDL file. This might not work just
like that, you probably need to include some other defnitions in your
newly
created IDL to get it compile. I can't remember exactly and I am not in
the
office this week, so this comes from my (bad) memory...
3. Once this succeeds (you can do this also before step 2) you need to
remove the [local] [call_as] statements from the IEnumstring interface.
Delete [local] and delete the complete [call_as(Next] HRESULT
RemoteNext...
This will work because Next and RemoteNext have the same layout. The local
and call_as is intended to make a distinction between local and remote
calls.
This way you can optimize remote calls, better than standard proxy/stub
generated code. Well we don't want to do this, that is why we remove it
from
the interface because it will complicate matters. I haven't hacked/reverse
engineered this one yet :-) Marshalling of IEnumString is a bit worser
now,
but as long as we can get it to work...
4. Now we have a plain old simple interface for which standard PS code is
generated (_i, _h files) Add them to your proxy/stub DLL and voila, you
now
have marshalling code for the IEnumString interface on the CE side. If you
register the PS DLL on the CE side it should work. There is no need for a
PS
DLL on the XP side as the data types are OLE automation compatible,
IEnumString is known there and oleaut32.dll and ole32.dll will do the work
for you. Note that the CE PS DLL will overwrite existing reg keys for
IEnumString, if they exist. But no worries, the reg keys will only
redirect
the marshaller to our own PS DLL instead of oleaut32.dll or ole32.dll

As John mentioned, there is a great article (mine:-) that does the same
thing for ISupportErrorInterface. If you have problems with it, you can
contact me directly at werner dot willemsens at xeikon dot com.
I can give you the code for IEnumVariant which is almost the same.

Last but not least. There is no future support for DCOM from CE6 onwards
(unfortunally), so if you can avoid it, you should. Or maybe you have more
resources to bride John than I have:-)

Succes
Werner



.

Loading