Re: Implementing IStream with ATL
"linearred" <nospam@nospam.nospam> wrote in message
news:%23FGcChOoIHA.2636@TK2MSFTNGP04.phx.gbl
I'm trying to implement a version of IStream to support a shell
extension thumbnail extractor (pre-Vista) using ATL, but I'm getting
stumped. The idea is to include the custom IStream object
implementation in the same dll server providing the extraction
object. I've tried modifying a "default" implementation from this
MSDN page:
http://msdn2.microsoft.com/en-us/library/ms752876(VS.85).aspx
First problem is that I'm a COM newbie, and this code looks
completely out of context to the old ATL books I'm having to use.
The example doesn't use ATL at all, but implements all the COM plumbing
by hand.
It's not clear to me how it's to be compiled or if its actually a COM
object, it doesn't actually seem to call CoInitialize
COM objects never call CoInitialize. The client has to call CoInitialize
before it can create the COM object in the first place.
it creates its
own non-<CComPtr> interface pointer, no indication of threading
model, etc..
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.
The problem is, I can't figure out how the client object (the
extractor COM object) is supposed to use the static OpenFile call to
set the file name and actually get the IStream object to open the
file.
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).
--
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