implement OleLoadPictureFile

[Reece Dunn]

2008/11/17 Michael Karcher <wine at mkarcher.dialup.fu-berlin.de>:
> Am Montag, den 17.11.2008, 13:09 -0800 schrieb Jeremy Drake:
>> 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).
> Oops. I just assumed there was one, but you seem to be right.

In shlwapi there is a SHCreateStreamFromFile with A, W and Ex versions
when given a filename.

>> 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.
> That is fair. Even different Windows versions are some times
> inconsistent with their error codes. It is more important what
> conditions exactly count as errors, and what happens to the data pointed
> to by lplpdispPicture parameter (unchanged / set to NULL / set to a
> valid object implementing IDispatch and IPicture). Most prominent error
> codes like "File not found" and "File is not in any supported format"
> should be checked, but that's it. You shouldn't even have told that the
> mapping is done directly in OleLoadPictureFile and not some lower layer
> invoked by OleLoadPictureFile, except if you are sure from a relay
> trace. Of course, if Wine developers find that *somewhere* error codes
> seem to be mapped, they are free to do the mapping in
> OleLoadPictureFile.

There should not be any mapping of error codes, except where tests
clearly show what is returned and that does not match what is returned
by the APIs being called to implement the function. Some of the errors
- such as "file not found" can be handled by the called APIs like
SHCreateStreamOnFile. There should still be tests for these codepaths
as well.

FWIW, applications are not usually concerned with the specifics of why
an API failed, just that it did. This, in addition to Windows changing
the return codes every release means that the error codes returned
won't make that big a difference; the only error codes you can rely on
will be those listed in the MSDN documentation.

- Reece