Hello,

I have created a simple Automation server using BCB 4.0.  I want to be
able to access it from MSVC++ 6.2 as an out-of-process server (please
don't throw any digital stones, it's what I have to use on the client
side).  Could someone please give me the fast course on how to do this
from MSVC++?

I tried the Class Wizard (MSVC++) and imported the type library
successfully.  But I am uncertain if this was the correct thing to do
and I still need to know what files to import/include to get the CLSID
to use in the CoCreateInstance() call.  Any other caveats or tips would
be appreciated.  If I have to register the server in the registry please
let me know the best method to do this.  I am guessing that the AutoCon
client sister example to AutoSrv, is using AutoSrv in-process so AutoSrv
did not have to register its class ID in the registry, but I could be
wrong.

Lastly, I assume that if I change the Automation server class interface
(methods, etc).  I have to remove the last CLSID registry entry and
register or new one?  Or how does this work?  If there are any really
good docs on this please point me to them.

Thanks.

Hi, WebHost Tech,

For registration easiest to use the TregSvr.exe that ships with D4 and BCB4.
Of course you unregister an old build then reregister.

As to the client side, no stone casting, it's actually far simpler in VC++.
When you look at VC++ examples, it is easy to get confused, because there
are several different ways of doing this. Most of the examples use older
techniques, like MFC and ClassGizzard. The most productive way to do this is
to use the new ATL stuff. This gets the client side syntax down to literally
a few lines of very clean code.

Here's how. In VC++5 and up you have a very useful pre-processor thing
called #import. If you search the MSDN samples for #import or "compiler COM
support", or_bstr_t, you will find some examples. Also you can find examples
in various third party books. An oldie with a few good but incomplete
discussions,  is "Professional Visual C++ 5 ActiveX COM Control Programming"
from Wrox. I'm sure there are better and newer ones now.

The way you use it is that you simply #import the executable of your server,
e.g FileName.exe, as if it were an #include. What this will do is generate
and include two automatically generated include files that you can find in
the .\Debug directory for a debug build. They are FileName.tli and
FileName.tlh, where the .tlh file #includes the .tli file. These are
wrappers. There are optional parameters on #import, look them up, e.g.
determining if vtable or dispatch/invoke (late bound) calls are used.

The upshot is that these includes provide wrappers for your server's
method/properties, smart interface pointers, smart variants and smart BSTRs,
so you don't have to deal with allocating and releasing them. Leaving out
error handling, try..catch blocks, a client side call to a server method and
a property fetch in a UNICODE build might look like this:

#import "MyServer.dll" no_namespace
...
_bstr_t  bstrWantedValue; // a smart BSTR
long      lValueToPass;
HRESULT   hRes;
VARIANT_BOOL   bRes;
...
hRes = CoInitialize(NULL);
...
// use smart Interface from #imported wrappers
IMyServerInterfacePtr  pServer(__uuidof(MyServer));
...
lValueToPass = 1234;
bRes = pServer->AdjustValue(lvalueToPass);
bstrWantedValue =  pObject->GetWantedValue();

_tprintf ("The string we got was %s", bstrWantedValue);

That's it. No need to even free the pointers. In a non UNICODE build you
obviously have to convert the BSTR to chars, using e.g.
WideCharToMultiByte().

Fernand

Oopsie, I didn't do global search and replace,
the third line of code above should be:

bstrWantedValue =  pServer->GetWantedValue();

Fernand