by the client therefore a safe array must be used. This brings up another
On 1 - add the [local] attribute to your interface. This
allow you to pass non-marshalable types through its
interface methods (like void*), but what you are really
after is a non-marshalable raw pointer inside the data
within the object (BYTE** without [out, size_is] or
BYTE* return type). Needless to say this only allows
C/C++ (and other low level languages) clients to use
that interface. Considering you are after efficiency
that shouldn't be an issue.
Here's an example for you:
[local, uuid(...)]
interface ILocal {
BYTE* getRawPointer();
void getAnotherRawPointer(BYTE** ptr);
}
As far as 2 - it must be Both. This is an apartment-
agnostic object, so it should never incur marshaling.
You aggregate the FTM by checking a checkbox on
the new ATL (simple) object wizard.
I guess it should be obvious, but you can only use
such object in-proc...
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================
"John" <John@discussions.microsoft.com> wrote in message
news:824CB90C-EE7F-4D5D-9BF4-5E956410677D@microsoft.com...
Alexander,
I really like this idea, but I have few more questions:
1) How does one remove the marshing support for a simple COM object that
was
generated by the ATL wizard?
2) Which threading model should be selected using the wizard, single,
apartment,
both, free or neutral ? (I am assuming free)
3) And finally how do you aggregate the FTM?
Any examples would be greatly appreciated.
Thanks
"Alexander Nickolov" wrote:
If you are worried about efficiency, even in the pull model
Igor described you shouldn't be using a safe array. I'm not
sure if this would be the right approach for you, but one
possibility is to return an interface pointer to an object
wrapping the data and have it return a raw pointer to the
data from a method (the interface must have no marshaling
support and the object should aggregate the FTM with all
its caveats). In fact you can push the object in this manner
as well, it's as easy as having the client pull it. In this way
the auxiliary object controls the lifetime of the data.
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================
"John" <John@discussions.microsoft.com> wrote in message
news:0D6652B4-CD7A-464D-B3CA-E861FC8F1038@microsoft.com...
Thanks Igor,
That was the alternate approach I was thinking about implementing. I
just
didn't
know if it was acceptable to allocate an array within a server and fire
an
event
and not free the array. And after giving it some more thought
implementing
it
is this manner would introduce major memory leaks if the client didn't
respond
to the events.
Thanks
"Igor Tandetnik" wrote:
John <John@discussions.microsoft.com> wrote:
I am developing an ATL object that acquires data from a CCD
detector,
I want to get the acquired image into a safearray and fire an event
with the safearray
as a parameter. In the event handler in the client I want to respond
to the event
and add the acquired image to a queue (for processing by another
thread).
So If I remember correctly it is the servers responsibility to
create
and free the
safearray. i.e. The server creates the safearray, fires the event,
and frees the
safearray on return from the event handler. The client must copy the
safearray in
the event handler to add to the queue.
Here is my problem, due to high frame rates, I don't want the client
to have to copy the safearray before adding it to the queue. I want
to take the safearray that was
allocated by the server and add it to the queue.
Don't pass safearray as a parameter of the event. The event with no
parameters would simply be a signal that a new frame is available. The
client would then turn around and call a method on the component to
retrieve the array. Since it's now an [out] parameter, the client is
responsible for freeing it.
--
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