ATL full control

[philbeck]

Using VC++ 6, I created an ATL exe server and then added a "full control" to it. On this control I chose to "implement connection points" and left everything else as default. I finally added a simple public method to make the speaker beep.

I then compiled it and saw that it was registered okay.

First question: based on all the defaults so far in the ATL wizard, is that registering process (at the end of compiling) the same as taking the resulting exe and typing
C:\> MY_ATL_EXE /REGSERVER

I then loaded VB and created a simple exe client. In the VB IDE I browsed for components and added MY_ATL_EXE control to the toolbar. It appeared on the toolbar but on trying to drop it on the form, an error message informed me that the "class" was not registered.

I then took just the atl exe and registered it on another machine. My understanding is that COM is location independant and therefore an activeX control hosted in an atl exe server should be able to run on a remote pc. Is this right?

After registering it I could see it in oleview and the activeX test container, from where I was able to call my beep method. But when I tried to use it from VB, I could only see it in the references dialog as a type library. I could not find it while browsing for components to add to the toolbar.

It was registered okay as a couple of lines of VB managed to call my beep method. It's just that I'm trying to understand why it didn't behave as an activeX control properly on either machine (and the behaviour was different on both machines) as far as VB went.

Thanks
Phil.

[kirants]

Not so familiar with VB, so I'll answer what I can.

Originally posted by philbeck
First question: based on all the defaults so far in the ATL wizard, is that registering process (at the end of compiling) the same as taking the resulting exe and typing
C:\> MY_ATL_EXE /REGSERVER

Yes.

I then took just the atl exe and registered it on another machine. My understanding is that COM is location independant and therefore an activeX control hosted in an atl exe server should be able to run on a remote pc. Is this right?

No. That would be DCOM.

[RNEELY]

I remember reading a while ago that the ATL wizard doesn't create a fully operational control by default. There are some extra things you have to do which are outlined in Chapter 10 of ATL Internals by Chris Sells and Brent Rector.

That being said, VB expects ActiveX controls to be in DLLs local to the machine on which the client app is running. You created an "ActiveX EXE" which is not a "traditional" ActiveX control. A C++ COM client could activate your "ActiveX EXE" via DCOM by specifying CLSCTX_REMOTE_SERVER in a call to CoCreateInstanceEx. Microsoft marketing did the industry a disservice by calling everything a control.