ActiveX automation server .exe, I want to fire event to one client ONLY.

I need to tweak one of our ActiveX automation server objects to only send an event to the one client that initiated an operation.

My object can have many clients, let's say two are connected, A and B.

A invokes a method.

How do I make sure that only A will receive the event when my object eventually calls the fire_OnEventX?

Every default and example I have seen will fire the event to all clients.  I am just wondering if if it is at all possible at this point.
LVL 7
HalfAsleepAsked:
Who is Participating?
 
pgnatyukConnect With a Mentor Commented:
There is a mistake in this suggestion - anyway all client will receive that event. But each one can check if this event is related (interested) to it or not.

So if you are trying to minimize the changes in the interface... when you fire an event, you need to add a state, and ID, whatsoever into your server and provide access to it, so the clients may understand if the event was about them or not.

Strange that evilrix has not proposed a design pattern for you. The question is not about COM or ATL.

For sure, there is no "built-in" or a "standard" COM or ATL way to fire event for a specific client. I'd say, it's one of the important concepts in the COM.
0
 
pgnatyukCommented:
Add a registration routine to your server - each client will have to cal, for example, Register method and the last one will return an ID. Next time, when the client calls the server, it has use this ID. So the server may notify only the registered clients or one specific client.
If I understand the task correctly.
I used this approach once in an application agent.
0
 
HalfAsleepAuthor Commented:
Thank you for the suggestion pgnatyuk.

I am hoping to avoid changing the interface though, which your suggestion will do as far as I understand it.  My hope is that there is a "preferred" or "standard" way in COM programming to be able to tell what client called your method and only fire events to this method.

In your suggestion, the client has to supply its allocated id for each call?  One of my problems is that this component has been in production for about 15 years, and I cannot easily change the interface (demand that users change their program).  The beauty of COM/ActiveX is that they can just replace my file and everything still works.  It is therefore very difficult for me to change the interface much.

Don't get me wrong, I think your suggestion would work perfectly.  I am just wondering if this is achievable in COM programming, without having to expose such a register func and passing your ID in every call.  I know that there is a form of "registration" that goes on in the background when a COM object has a client "connect/register" to it.  Is it possible to override/extend this method somehow and use any information there to distinguish clients, without changing the interface?  And also use this information when clients call methods?
0
Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
HalfAsleepAuthor Commented:
Thank you for the clarification.  I agree that this can be thought of outside of COM/ActiveX and more of design patterns etc.  I was just hoping that there was some support for this in COM withouth having to perform some magic or further complicate the high level interface between server and client.

I agree that the simplest approach (without having to implement my own ATL equivalent client registration handler) is to keep the ID within my object and having clients ask for it through a property.

I can certainly see that working and I thank you for the suggestion.  I have been so focused on trying to solve it within the technology/framework itself, that I guess I turned blind on the fact that I can solve it myself outside of COM/ActiveX.  Talk about not seeing the forest for the trees!  This does mean a change in the interface, but I guess maybe it is something that we will have to do to achieve what we want.

Thanks again,  if anyone else have more information or insight, I would still very much appreciate it.
0
 
HalfAsleepAuthor Commented:
Thank you very much for you input!  I am acceptiong your answer so that this question will remain visible in the EE database, so that people with the same issues can see how difficult it is to find any information about this topic.
0
 
pgnatyukCommented:
You are welcome.
0
All Courses

From novice to tech pro — start learning today.