Re: COM Servers - COM Discussion Boards

7-Jun-06 2:29

Can we create COM DLL Servers which runs in a different thread than the Client? If so, could anyone point me to some websites where I may read about them.

Thanks.....

---
With best regards,
A Manchester United Fan

The Genius of a true fool is that he can mess up a foolproof plan!

Roger Stoltz7-Jun-06 11:04

7-Jun-06 11:04

TechyMaila wrote:
COM DLL Servers which runs in a different thread than the Client

Depends on what you mean by different thread than the Client's...
You can create a server from a UI thread that is not the main thread of the client, i.e. a different thread than the one handling the GUI of the client, if such exist.

If you mean that the thread should not be in the same process as the client and it has to be a DLL server, as to my knowledge the only way I can think of is using DCOM where a surrogate process is created on the server machine. Then the thread in which the server runs would of course not be in the same process as the client hence a different thread.

If it doesn't have to be a DLL then a EXE server would have the server running in a different thread since it's an out-of-process server.

Not sure if I understood your question correctly... Unsure | :~

--
Roger

It's supposed to be hard, otherwise anybody could do it!

Regarding CodeProject: "resistance is pointless; you will be assimilated"

HakunaMatada7-Jun-06 17:40

7-Jun-06 17:40

Ok, First of all, thanks for your reply.

Now, let me clear your doubts. I have a client which creates and uses a COM Server. Its an InProc Server, so I assume that it runs in the same thread which created it. Am I right? With this scenario, what happens is, if something goes wrong with the server, it crashes the client too. I do not want this to happen. Also the server makes HTTP requests over the Web, so if the Internet connection is down, then the Server Sorta hangs in the middle while trying to find the connection which in turn hangs the Client.

What would be the best solution to tackle this problem? What I had thought about is, when the client creates the Server, it should automatically be created in a different thread in the same Process so that even if something goes wrong with it, then just the thread running the server can be destroyed, which I believe would not hurt the client. Is this possible? Or, Would I have to use DCOM and run the Server in a different Process? Would a DLL Server run in a separate Process or would it have to be an Exe? The COM Server is a DLL Server.

Thanks for your time.... Smile | :)

---
With best regards,
A Manchester United Fan

The Genius of a true fool is that he can mess up a foolproof plan!

Roger Stoltz7-Jun-06 22:23

7-Jun-06 22:23

TechyMaila wrote:
Its an InProc Server, so I assume that it runs in the same thread which created it. Am I right?

Yes, it's correct.

TechyMaila wrote:
if something goes wrong with the server, it crashes the client too. I do not want this to happen

Of course one never desires to crash the client. In fact, one never desires a crash at all. Wink | ;)

What do you mean by "if something goes wrong"? Usually you should write code that handles situations when something went wrong, such as checking return values, validating pointers and so forth.
You have to watch out for call chains that can generate C++ exceptions because you cannot pass exceptions through COM interfaces. If your using classes that throws exceptions you have to catch all exceptions before returning from a call to your server. Otherwise those exceptions could be the culprit that crashes your client.
The COM way of passing exceptions is the use of ISupportErrorInfo and IErrorInfo.

TechyMaila wrote:
What would be the best solution to tackle this problem?

As I understand it you have two problems: crashes and blocking calls.
Regarding the crashes you have to write code that tackles situations that can cause a crash.
Regarding blocking calls it's difficult to advise you since you haven't described what you're trying to do in more detail. I suggest you try to use asynchronous non-blocking methods, or at least something with a timeout.
Perhaps you can find something useful in this article[^].

Hope this helps
--
Roger

It's supposed to be hard, otherwise anybody could do it!

Regarding CodeProject: "resistance is pointless; you will be assimilated"

HakunaMatada7-Jun-06 22:59

7-Jun-06 22:59

Hi Roger,

Thanks for your Reply.

If I start explaining everything, then it would be like writing an epic.. Roll eyes | :rolleyes:

so could you just guide me to any tutorials which would create the COM Server in a different Thread. I could do it from the client itself, like start a new thread and then create the COM Server but can it be such that the COM Server automatically starts in a new thread when it is created? Confused | :confused:

And you are exactly correct about the exceptions. Although I do spend a lot of time writing error/exception handling routines while coding, it just happens.. sometimes. Frown | :(

I was talking about those situations. If an unhandled exception occurs, the least that I can do is exit gracefully without hurting the client. That is what I want to do.

Thanks for you time again.

---
With best regards,
A Manchester United Fan

The Genius of a true fool is that he can mess up a foolproof plan!

Roger Stoltz8-Jun-06 0:03

8-Jun-06 0:03

TechyMaila wrote:
If I start explaining everything, then it would be like writing an epic..

Well, we don't want that.... Big Grin | :-D

TechyMaila wrote:
guide me to any tutorials

I provided you with a link to an article in my previous post. Simply click it...
I haven't read the article though, but it could contain something useful to you since seems to be about multithreaded internet connections.

TechyMaila wrote:
the COM Server automatically starts in a new thread when it is created?

This is possible, but I haven't done it myself yet.
Google for "DllSurrogate", or search MSDN and you should find how it's done.
However, I seriously doubt this is the correct way to solve your problem. You have to fix the problems of the server if it's error prone or it will be virtually useless.
If you still have problems with exceptions, try catching all att the end of the try-/catch- block with catch(...) and put an ASSERT there so you can find the root cause of the problem.
If the error is considered beyond repair, then you can alert the client by returning a suitable HRESULT. The client is then responsible for server destruction and cleanup.

--
Roger

It's supposed to be hard, otherwise anybody could do it!

Regarding CodeProject: "resistance is pointless; you will be assimilated"

HakunaMatada8-Jun-06 1:06

8-Jun-06 1:06

Hi Roger,

Thanks a lot for your input. You have indeed been very helpful.

But I have one last query to ask you. Hope you don't mind. I have to Create a Window from the COM Server. I am using WTL for creating the Window with CMainFrameTraits. Now,I would have to create a new thread within the COM Server itself and launch the Window within the new thread. That is done. Now my problem is communicating between the COM Server thread and the Window thread. How do I communicate between threads? Since the Window thread and the COM Server thread will have to work like they are on the same thread with the COM Server calling the Window's functions and vice Versa, could you enlighten me on the topic.

Thanks once again...

---
With best regards,
A Manchester United Fan

The Genius of a true fool is that he can mess up a foolproof plan!

Roger Stoltz8-Jun-06 2:12

8-Jun-06 2:12

At first I suggest you read about how to use threads, both worker threads and UI threads.
Begin with Joe Newcomer's excellent article on the subject here[^].
Since you have a window you'll also need a message pump that will be provided for you with a UI thread. Refer to Joe's article about UI threads here[^].

As for how to communicate between threads you have a lot to pick from.
The cleanest way is by posting messages between the threads. This will keep the threads asynchronous which was the general idea to begin with.
There are a lot of articles on the subject in the CodeProject article section here[^].

Regarding WTL I cannot help you personally, but Michael Dunn has written quite a few great articles about WTL here[^].

Hope this helps
--
Roger

It's supposed to be hard, otherwise anybody could do it!

Regarding CodeProject: "resistance is pointless; you will be assimilated"

HakunaMatada8-Jun-06 17:28

Re: COM Servers [modified]

8-Jun-06 17:28

Thanks a lot Roger. Appreciate the time you have taken to help me. Rose | [Rose]

---
With best regards,
A Manchester United Fan

The Genius of a true fool is that he can mess up a foolproof plan!

Stephen Hewitt8-Jun-06 18:02

Stephen Hewitt

8-Jun-06 18:02

A COM object need not run in the thread that created it: it depends on the threading models of the thread that created it the threading model of the control. For example if an MTA thread tries to create an object that needs a STA thread the object will be created in a different thread (an STA thread) and its interface pointer will be marshaled to the client thread (an MTA thread).

Steve

Re: COM Servers [modified]

Roger Stoltz9-Jun-06 2:14

9-Jun-06 2:14

Stephen Hewitt wrote:
if an MTA thread tries to create an object that needs a STA thread the object will be created in a different thread

That's true.
But as I understood the OP's threading problem it was desired to have a DLL server running in a different process. What you've described still runs in the same process, even if it's another thread/apartment and threading model.

--
Roger

It's supposed to be hard, otherwise anybody could do it!

Regarding CodeProject: "resistance is pointless; you will be assimilated"

Stephen Hewitt9-Jun-06 18:01

Stephen Hewitt

9-Jun-06 18:01

Roger Stoltz wrote:
But as I understood the OP's threading problem it was desired to have a DLL server running in a different process.

I don't come to this conclusion from my reading of the OP's problem.

Steve

can not put com class's entry in the registry

Aamir Butt12-Jun-06 4:07

Aamir Butt

12-Jun-06 4:07

After having read all the replies to your post, I guess you are looking at how to make your COM Dll run in as a surrogate. There is a utility that comes with VisualStudio.NET called "Ole/Com Object Viewer". you can use this to use your dll as a surrogate process. It simply adds some registry entries so it can be done manually as well.

Tribute to Shog:
New CPhog is amazing especially with message posting, very well done Sir.

yang__lee6-Jun-06 20:39

yang__lee

6-Jun-06 20:39

Hi,
My friend asked me a question.
He said in his company he doesnt have enough access on the system
He develops com in process component on his machine but since he doesnt have access to write in registry, he can not register his component.
So in his client application he can not get the class if of his component.
Whats the remedy to this.
Anyway he can access his ATL com component in his MFC client application.

Leya

Re: can not put com class's entry in the registry

Milton Karimbekallil9-Jun-06 23:33

Milton Karimbekallil

9-Jun-06 23:33

There is no remedy for this Component information has to be there in the registry inorder to work CoCreateInstance.

Unless the component information is in the registry he can't access the component from MFC or any other client application. I dont understand what excatly you mean by "Anyway he can access his ATL com component in his MFC client application"

cheers...milton kb

connection points and sink interface

kk_mfc5-Jun-06 19:46

kk_mfc

5-Jun-06 19:46

Hi,

I had a COM server(USPServer) which fires some events and the client(DMPClient) which advises to this events will listen to these events.
server events: LinkStateChanged,MessageReceived

Usually we will write a Sink interface that is derived from the server event interface in the client side.

but the code in my project dosent have any sink interface that is derived from the server event interface.

I can see the advise part in the client.

in case of receiving the events in client side i had seen the following code.

<code>
::Invoke (DISPID dispidMember, REFIID riid, LCID lcid, WORD wFlags, DISPPARAMS FAR* pdispparams,
VARIANT FAR* pvarResult,EXCEPINFO FAR* pexcepinfo, UINT FAR* puArgErr)
{
METHOD_PROLOGUE (CUSPInterface, USPSink)

switch (dispidMember)
{
case 1:
pThis->OnLinkStateChangedEvent(pdispparams->rgvarg[0].iVal);
break;
case 2:
pThis->OnMessageReceivedEvent(pdispparams->rgvarg[1].iVal, pdispparams->rgvarg
[0].bstrVal);
break;
}

return S_OK;
}
</code>
Can any one please help me to understand the code.
and if any one has a sample code, please send me.
and why is he following this method instead of the regular method?
is there any advantage in following this method?

kk_mfc

User 2155975-Jun-06 20:56

User 215597

5-Jun-06 20:56

Which class implementation has this Invoke method?
Also, If you can share more info like - the Event Interface name, Advise code etc. then we will be able to help you in a better way

S o h a i l K a d i w a l a

modified 21-Apr-21 21:01pm.

kk_mfc5-Jun-06 21:35

kk_mfc

5-Jun-06 21:35

The event interface name: IUSPLinkSrvObjEvents
the methods in that are LinkStateChanged and Fire_MessageReceived

the mothod definition is in form

<br />
STDMETHODIMP CUSPInterface::XUSPSink::Invoke (DISPID dispidMember, REFIID riid, LCID lcid, WORD wFlags,DISPPARAMS FAR* pdispparams, VARIANT FAR* pvarResult, EXCEPINFO FAR* pexcepinfo, UINT FAR* puArgErr)<br />

Invoke is declared in CUSPInterface class

<br />
BEGIN_INTERFACE_PART(USPSink, _IUSPLinkSrvObjEvents)<br />
	virtual HRESULT __stdcall GetTypeInfoCount(unsigned int *pInfo) {return 0;};<br />
	virtual HRESULT __stdcall GetTypeInfo(unsigned int,unsigned long,struct ITypeInfo ** ) 	virtual HRESULT __stdcall GetIDsOfNames(const struct _GUID &,unsigned short ** ,unsigned  <br />
        int,unsigned long,long *) {return 0;};<br />
	virtual HRESULT __stdcall Invoke(DISPID dispidMember, REFIID riid, LCID lcid, WORD wFlags,<br />
	DISPPARAMS FAR* pdispparams, VARIANT FAR* pvarResult, EXCEPINFO FAR* pexcepinfo, UINT <br />
        FAR* puArgErr);<br />
END_INTERFACE_PART (USPSink)<br />

There is no decleration for XUSPSink or USPSink in the entire code itself

kk_vc

kk_mfc5-Jun-06 22:42

kk_mfc

5-Jun-06 22:42

The server component design is as follows:

A dialog based application is created and inserted a new atl object in that application.
the resulting will be a exe.

the client is using the .tlb of server and calling the methods.