Re: managing containers connected to a singleton COM
It's not that hard actually. You gut your COM object of any
significant code and move it into a shared C++ singleton class.
You register each COM object with the singleton once it is
instantiated by a client and unregister it when the client is
finished. From the COM object you simply forward all methods
on to the C++ singleton, possibly changing parameter types
beforehand (e.g. you might want to convert all BSTRs to a more
C++ friendly string class before passing them on to the singleton
for example). When you need to raise an event, the singleton
decides which clients it wants to notify and only invokes those
COM objects' Fire_XXX methods.
Microsoft MVP [VC], MCSD
MVP VC FAQ: http://vcfaq.mvps.org
<email@example.com> wrote in message
thanks a lot for the suggestion, I'll try it asap.
Regarding your way of "singleton behaviour", I'm very curious about it.
Particularly, I'm interested in how you can fire events to the different
instances of the control. Let's say you have 2 containers that instantiate
the COM object, and container1 calls a method. This method wants to fire
an event to container2, how do you achieve this ? If you simply Fire_xxx,
only the container that called the method will receive the event.
I agree with you that your way is better than a real singleton for several
Thanks for your support.
"Brian Muth" <firstname.lastname@example.org> ha scritto nel messaggio
Another possibility is to add another method passing the identifying
information of the client, something like....
Set r = CreateObject ("Mysingleton")
And store this identifying information on the server side. Now modify
Fire_xxxx code to use this information as a condition before firing the
It now occurs to me that for a singleton implementation, it may be hard
match up the id with the connection point. I tend to avoid singletons
the plague, preferring to implement "singleton behaviour" by simply
storing common data in either global variables or static member class
variables. Each client acquires their very own instance, but can still
access common information, which is why programmers tend to use
However, I digress. The first suggestion in my post is still applicable.