wine at jdrake.com
Mon Nov 17 15:09:07 CST 2008
On Mon, 17 Nov 2008, Michael Karcher wrote:
> The best way to do this is (in my oppinion) submitting the testcase
> again, but without the implementation, and marking the test todo_wine. A
> bug might be useful, but wouldn't a mail that contains the testcase as
> patch and the description in the comment part to wine-patches suffice?
Sounds good to me.
> Be sure to write your findings like (this is hypothetical, as I did not
> look at your patches and the OlePicture stuff till now): "Loads an image
> from a File. This is just like OleLoadPictureStream, but with a file
> name instead of a stream as source specification" and not like "To
> implement the function, you must create a stream from the file (use the
> standard OLE file stream object for that), pass the stream to
> OleLoadPictureStream and finally release the stream. In the error case
> you should do foo". The second form *is* just publishing what you saw in
> disassembly, so everyone who reads this mail carefully is in my oppinion
> everyone reading it carefully is in the same situation as you and
> shouldn't implement the function.
Hmm, looks like I don't really have to. Your detailed description is
about 90% accurate :). But the simple version should read "This is just
like OleLoadPicture"... I'll let you extrapolate the change to the
Note that the IDL defines the VARIANT parameter as "optional". If the
filename is not specified, you should pass a NULL stream to
Also, there is an OleLoadPictureFileEx, which adds the same 3 additional
paramters as OleLoadPictureEx adds over OleLoadPicture. You can probably
guess how that works... For the non-Ex versions, it may help you to know
about the constant LP_DEFAULT in olectl.h, which means "do the default
thing" to the extra params of the Ex version.
As far as the "standard OLE file stream object", if you know of one please
let me know. AFAIK, it is a pretty major oversight in the OLE IStream
APIs that there is not a function to create an IStream given a file (name
or handle). I've always had to roll my own wrapper around the file APIs,
or use a hack like the one in OleLoadPictureFilePath.
> Testcases on the other hand are fine. They just describe *what* to do,
> but not *how*. Especially for the error case testcases might be
Quite. Also in olectl.h are the error codes that these functions could
return. Unfortunately, I think it will be necessary to make some sort of
manual translation between the GetLastError returns from the file APIs and
these errors. Without spelling out the mappings from the disassembly, it
will probably be nearly impossible to get all of the cases exactly right.
The tests I have come up with so far verify the error codes that I've been
able to figure out how to trigger.
> > > Is there anyone out there who
> > > would volunteer to do it if I were to write a description of the
> > > function?
> I would do so, if its just some minutes.
I think that, as long as you are familiar with the APIs for dealing with
VARIANTs, this should be a very simple task. I would provide details
about how to deal with the VARIANT, but it may be misinterpreted as
knowledge gained from the disassembler. So I'll just leave you with a
couple of links to MS docs.
More information about the wine-devel