Re: creating a reference to a com object - COM Discussion Boards

creating a reference to a com object

20-Feb-07 21:05

Hi,
When i am trying to call a ActiveX dll(it has a form) from a VC client I am getting this error:

Run-time error '406':
Non-modal forms cannot be displayed in this host application from an ActiveX DLL,ActiveX Control, or Property Page.

Can anyone help me out with this??

Thanks in advance.

Priya.

shivapriyak19-Feb-07 4:30

19-Feb-07 4:30

Hi,
Can anyone tell me how to create a reference to a COM object...the COM object is Control.dll ...... I want to create a pointer to this COM and access methods from it.
Thanks in advance.

Priya.

Roger Stoltz19-Feb-07 11:18

19-Feb-07 11:18

You don't create a reference to a COM server, you create the server by a call to ::CoCreateInstance() and if the server could successfullly be created you'll get the interface pointer that you requested in the call.
Learn the basics of COM in this CodeProject section: clickety[^].
Michael Dunn's articles would be a good starting point.

shivapriyak19-Feb-07 18:21

19-Feb-07 18:21

Hi,
I guess the way my question is formed is wrong.I am sorry about that. Actually my requirement is , I have a vb project which is using a COM Component in it. Now i have created a separate VB project and i want to use the same COM component which is present in the other vb project instead of again adding the COM component in my proj. Thus i want to avoid creating 2 instances of the COM but instead create a reference to existing COM object which is included in a VB client.
I guess u have got my problem. how to do it?
Kindly help me with this.
Thanks in advance

Priya.

Tim Paaschen19-Feb-07 19:45

Tim Paaschen

19-Feb-07 19:45

This is not a trivial task. A COM DLL is always an in-proc server - which means that it is executed within the process of the client application. Windows does separate different processes quite good.
The approach which I would recommend is to change the COM server to an out-proc (EXE) server. Then make it a singleton server and the two applications can share one instance of it - as long as both clients run in the same user context.
If you don't have access to the sources of the COM server, you will have to implement some other means of inter-process communication. Eventually it is possible to register the COM server in the ROT (running object table) to share it. However, I have never tried to use this approach.

Regards,
Tim

Roger Stoltz19-Feb-07 22:22

19-Feb-07 22:22

Tim Paaschen wrote:
A COM DLL is always an in-proc server - which means that it is executed within the process of the client application.

Not quite true, Tim.
You can run the DLL server in a surrogate process. This even means that you can run a DLL server that is executing on another computer using DCOM.
Read this[^] for more info.

The exe-server solution and registering in the ROT would do fine, but that may slow things down from the VB-client perspective.
I suggest the use of aggregation.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

shivapriyak19-Feb-07 23:44

19-Feb-07 23:44

Hi,
I understood ur approach,but as i am new to this COM thing..I do not know how to implement. First of all how to convert an in-proc COM instance to an out-proc COM instance so that both the clients can share the same dll. Secondly, How to convert it to a singleton server?? The last registering part which u told, to register in ROT, I am not sure I understood that.
Regards,

Priya.

Tim Paaschen20-Feb-07 1:25

Tim Paaschen

20-Feb-07 1:25

shivapriyak wrote:
First of all how to convert an in-proc COM instance to an out-proc COM instance

The easiest way is to create a new project and select an COM EXE (out-proc) server right from the beginning. If you want to convert your project, create a new dummy out-proc server and reproduce the required settings and code in your project.

If your server derives from CComCoClass, you can use the DECLARE_CLASSFACTORY_SINGLETON macro. However, be awae that this only works for clients started by the same user.

Regarding the Running Object Table have a look at the MSDN[^] or this article[^].

Regards,
Tim

Roger Stoltz19-Feb-07 22:27

19-Feb-07 22:27

I suggest you use COM aggregation; a way to encapsulate an inner COM server inside an outer and expose interfaces from the inner server to clients of the outer server.
Have a look in MSDN here[^] and at CodeProject here[^].

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

shivapriyak19-Feb-07 23:48

19-Feb-07 23:48

Hi,
I am new to this COM thing..but let me see if i got u right. COM aggregation is a method by which v can encapsulate a inner COM componet within another and the client can call the interfacing methods of the outer component instead of the inner COM.
So, How will this solve my issue?? Actually what i need is 2 clients accessing the same COM component instance..how v can get this??Plz explain.
Thanks.

Regards,

Priya.

Roger Stoltz20-Feb-07 0:11

20-Feb-07 0:11

shivapriyak wrote:
So, How will this solve my issue?? Actually what i need is 2 clients accessing the same COM component instance.

Ok, I misunderstood your problem.
Then I suggest you do what Tim suggested: create an exe-server and register the instance in the Running-Object-Table (ROT). Clients to the server can then request an already running instance of the server from the ROT. If it's essential that there is only one single instance running at the same time you can implement it as a singleton.
Perhaps this[^] article can help you. It's partly written in C#, but the concept is the same no matter the language.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

shivapriyak20-Feb-07 1:19

20-Feb-07 1:19

Hi,
I went thru the article.
What i understood is that the COM has to be registered and running in the ROT table. Then both the clients can access the same running instance of the COM dll by getting pointers to it.Correct me if i am wrong...
But i am afraid i don't know C# can u tell me how to do this in vb??
both my clients r vb applic only..

Thanks

Priya

Roger Stoltz20-Feb-07 2:47

20-Feb-07 2:47

shivapriyak wrote:
What i understood is that the COM has to be registered and running in the ROT table. Then both the clients can access the same running instance of the COM dll by getting pointers to it.Correct me if i am wrong...

No need for correction, you've got it.

shivapriyak wrote:
i don't know C# can u tell me how to do this in vb?

Sorry mate, unfortunately I don't know how the synthax looks in VB for doing COM.
However, it's the flow that's important; in what order to do things and what IRunningObjectTable methods to call since it will be the same regardless of the language used. You'll have to translate it to VB by yourself.

In addition to the links that Tim provided you with, have a look at this[^], an article in MS Systems Journal written by Jeff Prosise about the use of ROT and monikers.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

shivapriyak20-Feb-07 21:02