Hi Nikolay,
I came through this while testing COM/OLE init stuff and tried to use OleGetClipboard to probe actual OLE state in Windows. The fact is that on Windows OleGetClipboard succeeds for me even if Ole is not initialized (and this is not the case in Wine). So straightforward test will be failing on Windows (returning S_OK when I expect and error in Wine). It is probably some separate compatibility issue. My test used to assign 0xdeadbeef to the interface pointer and release any non-null interface after the call regardless of status (as I saw as a common practice in ole tests), so it crashed under wine. I just thought it is appropriate to zero pointer on output as long it is a standard convention. I could possibly search for some conditions when OleGetClipboard fails on Windows to make a valid test like this. Does it make sense or better leave it as is for now?
Thanks, Paul.
On 01/13/2016 02:05 PM, Nikolay Sivov wrote:
On 13.01.2016 13:23, Paul Gofman wrote:
Signed-off-by: Paul Gofman gofmanp@gmail.com
dlls/ole32/clipboard.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/dlls/ole32/clipboard.c b/dlls/ole32/clipboard.c index ca9520f..b871bbc 100644 --- a/dlls/ole32/clipboard.c +++ b/dlls/ole32/clipboard.c @@ -2201,6 +2201,7 @@ HRESULT WINAPI OleGetClipboard(IDataObject **obj) TRACE("(%p)\n", obj);
if(!obj) return E_INVALIDARG;
*obj = NULL;
if(FAILED(hr = get_ole_clipbrd(&clipbrd))) return hr;
Hi, Paul.
This is to handle a case when OLE was not initialized, right? If so, it should be easy to add a test for it. It makes sense to zero it as a common convention for out interface pointers, but a test won't hurt.