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 detailed version.
Note that the IDL defines the VARIANT parameter as "optional". If the filename is not specified, you should pass a NULL stream to OleLoadPicture.
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 interesting.
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.
http://msdn.microsoft.com/en-us/library/ms221673.aspx http://support.microsoft.com/kb/238981