Re: [Libreoffice] Clipboard handling on Windows

I stand under correction, but I believe the correct answer is that ideally, you need to support 
**both**.

I think the second one is the newer one, and Windows provides some support for interfacing 
applications using the first
one with applications using the second one.
Which is why you see some of the formats, but not all of them, when you use the second API.

Ideally, I think LO needs to get a list from both API's and eliminate duplicates.

Of course, you could always fire up Excel under a Windows debugger, put breakpoints on all of those 
API entry points,
and see what it does :-)

-- Noel Grandin


Kohei Yoshida wrote:
> Hi fellow hackers,
>
> While investigating this bug
>
> https://bugs.freedesktop.org/show_bug.cgi?id=33100
>
> which involves Windows' clipboard handling, I've come to the realization
> that, there are two ways to communicate with the clipboard on Windows.
>
> One is to use the regular clipboard API
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms648709%
> 28v=vs.85%29.aspx
>
> which allows you to open, close, query the available formats, and fetch
> the raw clipboard data stream for a requested format.
>
> The other way is to obtain the IDataObject instance from the clipboard,
> and fetch the clipboard data stream from that object.
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms688421%
> 28v=vs.85%29.aspx
>
> First of all, I don't quite understand why two different ways, and what
> the differences are between the two.
>
> Our current clipboard implementation in dtrans uses the
> IDataObject-based approach.
>
> Now, as I discovered while investigating the bug, using the IDataObject
> method does not necessarily return all available clipboard formats,
> whereas using the regular clipboard API does.  I was thinking naively
> about perhaps replacing our current IDataObject-based approach with the
> clipboard API based one, but the whole data transfer code does more than
> just handling the clipboard, so I don't really know how feasible
> replacing it would be...
>
> Does anyone have a better grasp on why we do it the way we do?
>
> Feedback and suggestions very much appreciated.  Also, if anyone wants
> to grab Bug 33100, s/he will be more than welcome. :-)
>
> Thanks,
>
> Kohei 

Disclaimer: http://www.peralex.com/disclaimer.html