Fireing events to two apps?? 
Author Message
 Fireing events to two apps??

Hi
I'm using ATL ConnectionPoints... to notify my clients what the other client
does. The problem is when one client raises an event the other doesn't
recieves any notification.

Any suggestions

/Stefan



Sat, 21 Feb 2004 14:49:33 GMT  
 Fireing events to two apps??
Just make it a singleton and all clients will get all events.


Quote:
> Hi
> I'm using ATL ConnectionPoints... to notify my clients what the other
client
> does. The problem is when one client raises an event the other doesn't
> recieves any notification.

> Any suggestions

> /Stefan



Sun, 22 Feb 2004 00:30:29 GMT  
 Fireing events to two apps??
Except that all the "experts" say not to use COM Singletons....

I had a similar requirement and ended up creating an internal class that was
based on the Singleton pattern and when my objects were instantiated, would
register themselves with that object, then when events occurred, the
singleton object would then run through the list of registered objects and
call a Fire method on each.

Kevin


Quote:
> Just make it a singleton and all clients will get all events.



> > Hi
> > I'm using ATL ConnectionPoints... to notify my clients what the other
> client
> > does. The problem is when one client raises an event the other doesn't
> > recieves any notification.

> > Any suggestions

> > /Stefan



Sun, 22 Feb 2004 07:41:38 GMT  
 Fireing events to two apps??
Avoiding jumping through hoops like this is why I ignore the advice
to stay away from COM singletons :-)  By all means, know the
pitfalls of COM singletons, but if they solve the problem at hand,
I would say use them.

Actually, _any_ singleton pattern is fraught with pitfalls.  COM
singletons solve some of the worst pitfalls by managing threading
issues.

Well, anyway, YMMV, etc.  If you do decide to use COM
singletons, just note the following:

1) In-process singletons are only per-process singletons.
2) Remote server singletons can be defeated by being
instantiated on a per-user basis - a major pitfall.  This can be
managed by having them run as a particular user when
security is set up via DCOMCNFG or otherwise.
3) Remember the three legs of the singleton tripod:
3a) REGCLS_MULTIPLEUSE when registering class objects.
3b) DECLARE_CLASS_FACTORY_SINGLETON (the
wizard won't do this).
3c) Even with the class factory "singletonized", be sure that
multiple copies of the process won't be running at the same
time.

Did I miss anything?


Quote:
> Except that all the "experts" say not to use COM Singletons....

> I had a similar requirement and ended up creating an internal class that
was
> based on the Singleton pattern and when my objects were instantiated,
would
> register themselves with that object, then when events occurred, the
> singleton object would then run through the list of registered objects and
> call a Fire method on each.

> Kevin



> > Just make it a singleton and all clients will get all events.


message

> > > Hi
> > > I'm using ATL ConnectionPoints... to notify my clients what the other
> > client
> > > does. The problem is when one client raises an event the other doesn't
> > > recieves any notification.

> > > Any suggestions

> > > /Stefan



Mon, 23 Feb 2004 01:20:27 GMT  
 Fireing events to two apps??
No, you've been thorough :)

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD

MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================


Quote:
> Avoiding jumping through hoops like this is why I ignore the advice
> to stay away from COM singletons :-)  By all means, know the
> pitfalls of COM singletons, but if they solve the problem at hand,
> I would say use them.

> Actually, _any_ singleton pattern is fraught with pitfalls.  COM
> singletons solve some of the worst pitfalls by managing threading
> issues.

> Well, anyway, YMMV, etc.  If you do decide to use COM
> singletons, just note the following:

> 1) In-process singletons are only per-process singletons.
> 2) Remote server singletons can be defeated by being
> instantiated on a per-user basis - a major pitfall.  This can be
> managed by having them run as a particular user when
> security is set up via DCOMCNFG or otherwise.
> 3) Remember the three legs of the singleton tripod:
> 3a) REGCLS_MULTIPLEUSE when registering class objects.
> 3b) DECLARE_CLASS_FACTORY_SINGLETON (the
> wizard won't do this).
> 3c) Even with the class factory "singletonized", be sure that
> multiple copies of the process won't be running at the same
> time.

> Did I miss anything?



> > Except that all the "experts" say not to use COM Singletons....

> > I had a similar requirement and ended up creating an internal class that
> was
> > based on the Singleton pattern and when my objects were instantiated,
> would
> > register themselves with that object, then when events occurred, the
> > singleton object would then run through the list of registered objects
and
> > call a Fire method on each.

> > Kevin



> > > Just make it a singleton and all clients will get all events.


> message

> > > > Hi
> > > > I'm using ATL ConnectionPoints... to notify my clients what the
other
> > > client
> > > > does. The problem is when one client raises an event the other
doesn't
> > > > recieves any notification.

> > > > Any suggestions

> > > > /Stefan



Mon, 23 Feb 2004 01:43:54 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Fireing an event from a different thread!

2. Fireing events problem!

3. Fireing events, and sinking them prob.

4. Fireing events from a multithreaded ActiveX ?

5. Fireing structs in ATL

6. Firing events between two EXEs

7. Two interfaces and connection points/events

8. Two MFC event handling questions for the Gurus...

9. Double Click fires two single click events??

10. Two different Event handlers?

11. Share Data Between Two Apps?

12. Can SDI App Have Two Different Split Views

 

 
Powered by phpBB® Forum Software