ActiveX OCX vs. COM Server vs. COM...?
Author
Dear All:
Hi! Since the people who go to this board are often the most knowledgable people I run into on the internet for technical problems, I figured I'd post in the general board about this non-gaming related problem I've run into...
I've recently run into a situation where a colleague of mine is suggesting that an ActiveX OCX control I wrote should be a "COM Server" instead. He claimed that using the OCX control would cause apps to break if a new version of the control would break (which I *thought* was untrue, because OCX Controls follow the COM contract), and he wanted the component to be "constantly running" in the background and for his part of the program to simply access it. This led me to question a couple of things that I had often assumed:
1) That ActiveX is COM. I always thought that ActiveX and COM were interchangable concepts.
2) What the heck distinguishes a "COM Server" component from an ActiveX component, or a normal COM component? Come to think of it, what's a "COM Server" anyways?
3) Is it even possible to write a "COM Server" component in Visual Basic 6?
I've looked on Google, but it has no relevant resources on the topic (searches for "COM Server component", for example, refer to you to IIS Server components, which wasn't what he was talking about: he was talking about a component that was constantly running in the background of a local machine, which people could access programatically on the local machine through a common interface).
Anyways, any help is greatly appreciated, as he's stumped me and my usual resource (Google) to begin searching for topics has utterly let me down. Thanks for any help you can provide, I owe you all a big one. =)
1) ActiveX is a technology that utilises COM - it is the new name for OLE.
2) An ActiveX component _should_ exist for as long as you are using it. By using reference counting the COM subsystem knows when to unload a DLL/EXE due to it no longer being in use.
A COM server is an executable that contains COM components. The program can run all the time or just be invoked when those components are needed.
One project I was recently involved in did a bit of both. The COM server was a framework sitting behind several applications that needed to communicate. The framework provided common configuration information, licensing information etc. It was invoked when the first call was made to one of its COM interfaces, then it remained running in the system tray for future interaction.
3) I don't know, sorry. VB is not my forté.
2) An ActiveX component _should_ exist for as long as you are using it. By using reference counting the COM subsystem knows when to unload a DLL/EXE due to it no longer being in use.
A COM server is an executable that contains COM components. The program can run all the time or just be invoked when those components are needed.
One project I was recently involved in did a bit of both. The COM server was a framework sitting behind several applications that needed to communicate. The framework provided common configuration information, licensing information etc. It was invoked when the first call was made to one of its COM interfaces, then it remained running in the system tray for future interaction.
3) I don't know, sorry. VB is not my forté.
VB5/6 can create a number of different com components, including:
1. ActiveX controls - which are mainly used to provide the calling application with a self-contained object which has functionality and a user interface which can be incorporated into the calling application's window (e.g. a pie chart control)
2. ActiveX DLLs - which are mainly used to provide the calling application with a self-contained object which has functionality and no user interface (e.g. a communications DLL, an XML reader DLL)
3. ActiveX Exes - which are applications in their own right which expose objects to other calling applications (e.g. like Excel's document objects, although they dont have to have a user interface), these applications can be running all the time (placed in startup), or run when objects are invoked
Out of these, it is ActiveX Exes which usually run in a separate process to the calling app, so ActiveX Exes are the closest thing to a server component in a client server architecture.
I have limited my discussion here to applications which call com components resident on the same pc. VB also supports distributed COM, but I have never used that functionality.
1. ActiveX controls - which are mainly used to provide the calling application with a self-contained object which has functionality and a user interface which can be incorporated into the calling application's window (e.g. a pie chart control)
2. ActiveX DLLs - which are mainly used to provide the calling application with a self-contained object which has functionality and no user interface (e.g. a communications DLL, an XML reader DLL)
3. ActiveX Exes - which are applications in their own right which expose objects to other calling applications (e.g. like Excel's document objects, although they dont have to have a user interface), these applications can be running all the time (placed in startup), or run when objects are invoked
Out of these, it is ActiveX Exes which usually run in a separate process to the calling app, so ActiveX Exes are the closest thing to a server component in a client server architecture.
I have limited my discussion here to applications which call com components resident on the same pc. VB also supports distributed COM, but I have never used that functionality.
Author
Ah, excellent! That makes a lot of sense: I thought that ActiveX was COM. He had me all confused. =)
As for the ActiveX EXE thing, now I know something to look further into... and it's good to hear that VB can do it. =) Thanks for the help guys! =)
As for the ActiveX EXE thing, now I know something to look further into... and it's good to hear that VB can do it. =) Thanks for the help guys! =)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement