Re: Multiple connection points and memory handling
- From: "Igor Tandetnik" <itandetnik@xxxxxxxx>
- Date: Wed, 6 Jul 2005 06:46:19 -0400
"arun" <spaace@xxxxxxxxx> wrote in message
news:1120624106.701270.21810@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> My Vairants[in, out] would have arrays in them, which i think would
> qualify as embedded pointers. So when the server calls the clients who
> have implemented the sinks, the embedded memory, would have to be
> freed by the client (right ?)
[in, out] parameters do require special handling - see Alexander's reply
and the article he refers you to. There's also a tricky semantic
question - if you have two event handlers, and the two return different
values through the [out] parameters, you have to figure out how to
process this data.
> I was considering this a bit messy and i was wondering whether its ok
> to assume the luxury of having only 1 client per connection point so
> that i need not handle this mess within a big fat loop.
You can actually enforce "one client" limit if you want. In the
generated proxy code, find where it derives from
IConnectionPointImpl<SomeClass, &DIID>. Add a third template parameter
of CComUnkArray<1> (the default value is CComDynamicUnkArray which can
hold an arbitrary number of pointers). Now a second client calling
Advise would get CONNECT_E_ADVISELIMIT error.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
.
- Follow-Ups:
- References:
- Multiple connection points and memory handling
- From: arun
- Re: Multiple connection points and memory handling
- From: Igor Tandetnik
- Re: Multiple connection points and memory handling
- From: arun
- Multiple connection points and memory handling
- Prev by Date: Re: Browsing for files...
- Next by Date: IShellExecuteHook::Execute()
- Previous by thread: Re: Multiple connection points and memory handling
- Next by thread: Re: Multiple connection points and memory handling
- Index(es):
Relevant Pages
|