Re: Implementing IStream with ATL
linearred <nospam@nospam.nospam> wrote:
Thanks for the reply. Right off the bat, can you recommend any
relatively recent COM or ATL books or site references?
"Essential COM" (and, optionally, "Effective COM") by Don Box on raw COM
(no ATL, all code done from first principles).
"ATL Internals" by Rector and Sells is the ultimate ATL resource, but
may be too dense for beginners. "Beginning ATL 3 COM Programming" and
"Professional ATL 3 COM Programming" by Richard Grimes et al are often
recommended, but I haven't personally read either.
The only
stuff I've been able to locate is typically 8-10 years old, and
doesn't always align with what I see the wizards creating in VS2008.
There's ATL Internals 2nd edition, circa 2006. But of course no dead
tree edition can hope to be up to date for very long. The books are good
at giving you a high-level picture of how things fit together
architecturally, but you can't expect the small details to remain
unchanged.
The example doesn't use ATL at all, but implements all the COM
plumbing by hand.
Please pardon my lack of experience with COM, but it seems like it's
missing all the behind the scenes support for things like marshalling
and threading.
I'm not sure what support you expect to see. Most of the time,
marshalling and threading are handled transparently by COM runtime.
Can you actually pass the IStream interface pointer
this example creates to something else that expects an IStream
Of course. The class would be pretty useless otherwise, wouldn't it?
when
you don't actually know what the "something else" is going to do with
it? (That's the dilemna I have with my IStream.)
What do you mean, you don't know? It's going to call IStream's methods
on it. What else can it do with an interface pointer?
The example creates the COM object for internal use only. It's not
intended to be registered and be externally creatable. So the
registration-related parts are omitted.
I can see that in some cases, but in this case, I have to hand the
interface pointer off to GDI+'s IStream-based Bitmap constructor
(more on why to follow).
That's OK. The example was going to hand the pointer off to XmlLite
component. So you are actually in a very similar situation.
I'm not sure what happens to the IStream on
the other side of the constructor call.
Its methods are called, of course.
Do you think it would be
reasonably safe to pass this particular example's IStream pointer to
something like GDI+?
I don't see why not. Though GDI+ Bitmap object has a constructor that
takes a file name, so I don't quite see the point of the exercise.
Typically, a shell extension implements IShellExtInit::Initialize.
That's how they get a shell object to act on. I'm not familiar with
"thumbnail extractor" (unless you mean IExtractImage, but that one
doesn't use an IStream).
The actual pre-Vista thumbnail extractor protocol isn't even formally
defined in the MSDN docs as far as I can tell. The individual
interfaces it uses, IPersistFile, IExtractImage/2, and IRunnableTask
are defined separately, but there's nothing other than a couple of
paragraphs in a couple of old Dino Esposito MSDN magazine articles
that discuss only generally how they actually relate to each other to
accomplish thumbnail extraction.
Ok then, IPersistFile::Load is where the file name is handed to you.
--
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