Board index » cppbuilder » Conceptual question on Event sinks and event firing..?

Conceptual question on Event sinks and event firing..?

Hi-
I have several COM objects built and working. They fire events to owners
as they should.
A new wrinkle has been introduced lately that I have been unable to
answer (even after searches in my books and on MSDN)...

I need to be able to manage the life of these objects by using another
EXE COM server that will in turn accept requests from other clients and
hand off a Dispatch pointer to an object, after either building one or
determining that an existing one is the proper one. No Problem so far..

Since the new client will have the dispatch pointer it can make calls on
the object. But how can it sink events.? The object (event source) knows
nothing of the client, so how can it know to call the client on an
event.?

I feel like there is a step missing in getting the connection fully
established. Doesn't the client need to inform the object that it wants
to sink events? If this is the case (I don't see how it could not be)
how does the client notify the object that it wants to see the events.?

An associate wrote a test bed in VB and used "WithEvent" on one of my
objects. It appears that this made the connections for both events and
calls on my objects. What is the equivalent in C(++)..? Or am I barking
up the wrong tree..?

TIA

 

Re:Conceptual question on Event sinks and event firing..?


Bart,

why can't a new client ( that was hadned off an interface pointer ) do
the same thing as other clients do? You say you have clients that are
getting the events, so somehow they did it already? TEventDispatcher
class in BCB4 helps with this.

Alex

Quote
Bart wrote:

[snip]

Re:Conceptual question on Event sinks and event firing..?


Hi Alex-
Thanks for the reply.
I guess my description wasn't very descriptive...<grin>

The clients that are receiving the events now "own" the objects by
virtue of having them in their address space. This is just a testbed to
ensure that basic functionality is in place.

The new configuration (previous description) is what is introducing the
wrinkle (and my lack of understanding only compounds the problem). In
the new configuration the same ownership does not exist, hence the need
for passing interface pointers around.

I guess what I need to know is how does the event sink "register" its
desire to get events with the source, regardless of address space, or
ownership..?

Quote
"Alex Bakaev [TeamB]" wrote:

> Bart,

> why can't a new client ( that was hadned off an interface pointer ) do
> the same thing as other clients do? You say you have clients that are
> getting the events, so somehow they did it already? TEventDispatcher
> class in BCB4 helps with this.

> Alex

> Bart wrote:
> [snip]

Re:Conceptual question on Event sinks and event firing..?


Well, usually COM creates an object pointer for you. And if you want to
pass it around, you have to marshal it. Assuming you marshaled it, you
can do the same thing your current object does to register its event
sink. TEventDispatcher, utilcls.h.

Alex

Quote
Bart wrote:

[snip]

Re:Conceptual question on Event sinks and event firing..?


Hi, Bart,

What that one word (WithEvents) does in VB is totally awesome. The BCB
equivalent is not pretty. Doing the client sink manually is deep, Man, but
best left to real Mohicans. Yeah, right, Alex, "just marshall".

The new TEventDispatcher saves a lot of hand coding, but apparently it's
still not documented. The (lone) WordEvents example on Code Central does not
even build with BCB4.SP1. Don't know why Bruneau never fixed it. There have
also been necessary fixes to utilcls.h that Bruneau mentioned "en passant"
in this newsgroup (like missing semicolons - I'm not even talking about
enhancements), but these have apparently never been put into a distribution.
To call this a mess is charitable. Holler here or howl at the moon if you
need a version of these items that work, or line up for BCB5.

Hey, I'm not much of a "down on my knees with Templates" kind of guy. I like
clean and get-there-fast. I just want the plumbing to work, I'm not into
{*word*180}ing the pipes. So let me share a slacker's trick. It might or might not
be enough for your needs. Binh Ly's EventSinkImp utility (designed for
Delphi) can be run on a typelib or compiled program, and creates a little
proxy VCL component for your COM object that gives you a similar kind of
thing as WithEvents does, namely you get all your events in the Object
Inspector. Yesss, Bingo! If you need fancier, all the source is there
anyway, so you can extend it. It's forking brilliant. Binh Ly also has a
whole set of tutorial papers on COM issues on that site, with special
attention to making Borland tools usable for COM work. They should have
hired Binh Ly long ago.

Anyway, using EventSinkImp's been working great for me both in BCB4 and D4.
The only downside is that you have to use EventSinkImp to make and install a
little proxy component for every COM object you want to sink from. It beats
reverse engineering Borland's ATL code. Check it out:

http://www.castle.net/~bly/files/EventSinkImp.zip

Fernand

Alex Bakaev [TeamB] <al...@jetsuite.com> wrote in message
news:37FBD399.646752D4@jetsuite.com...

Quote
> Well, usually COM creates an object pointer for you. And if you want to
> pass it around, you have to marshal it. Assuming you marshaled it, you
> can do the same thing your current object does to register its event
> sink. TEventDispatcher, utilcls.h.

Re:Conceptual question on Event sinks and event firing..?


Fernand-
Thanks for stepping up to the plate. I appreciate the help and info.
Quote
Fernand Raynaud wrote:

> Hi, Bart,

> What that one word (WithEvents) does in VB is totally awesome. The BCB
> equivalent is not pretty. Doing the client sink manually is deep, Man, but
> best left to real Mohicans. Yeah, right, Alex, "just marshall".

> The new TEventDispatcher saves a lot of hand coding, but apparently it's
> still not documented. The (lone) WordEvents example on Code Central does not
> even build with BCB4.SP1. Don't know why Bruneau never fixed it. There have
> also been necessary fixes to utilcls.h that Bruneau mentioned "en passant"
> in this newsgroup (like missing semicolons - I'm not even talking about
> enhancements), but these have apparently never been put into a distribution.
> To call this a mess is charitable. Holler here or howl at the moon if you
> need a version of these items that work, or line up for BCB5.

> Hey, I'm not much of a "down on my knees with Templates" kind of guy. I like
> clean and get-there-fast. I just want the plumbing to work, I'm not into
>{*word*180}ing the pipes. So let me share a slacker's trick. It might or might not
> be enough for your needs. Binh Ly's EventSinkImp utility (designed for
> Delphi) can be run on a typelib or compiled program, and creates a little
> proxy VCL component for your COM object that gives you a similar kind of
> thing as WithEvents does, namely you get all your events in the Object
> Inspector. Yesss, Bingo! If you need fancier, all the source is there
> anyway, so you can extend it. It's forking brilliant. Binh Ly also has a
> whole set of tutorial papers on COM issues on that site, with special
> attention to making Borland tools usable for COM work. They should have
> hired Binh Ly long ago.

> Anyway, using EventSinkImp's been working great for me both in BCB4 and D4.
> The only downside is that you have to use EventSinkImp to make and install a
> little proxy component for every COM object you want to sink from. It beats
> reverse engineering Borland's ATL code. Check it out:

> http://www.castle.net/~bly/files/EventSinkImp.zip

> Fernand

> Alex Bakaev [TeamB] <al...@jetsuite.com> wrote in message
> news:37FBD399.646752D4@jetsuite.com...
> > Well, usually COM creates an object pointer for you. And if you want to
> > pass it around, you have to marshal it. Assuming you marshaled it, you
> > can do the same thing your current object does to register its event
> > sink. TEventDispatcher, utilcls.h.

Other Threads