Re: [Libreoffice] Clipboard handling on Windows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/12/11 11:28, Kohei Yoshida wrote: > Hi fellow hackers, > > While investigating this bug > > https://bugs.freedesktop.org/show_bug.cgi?id=33100 > > which involves Windows' clipboard handling, Don't want to hijack anything, but wonder if "wine program->LO" clipboard behaviour is related to this? When I copy stuff from from programs in wine and later paste them into writer with Ctrl+V, the paste is happening at _the end of_ the document (not where the cursor is). However, if I Ctrl+Shift+V and paste unformatted, paste is normal. my 2cents - sorry if this is misleading and/or unrelated... best Arno -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7ZOzAACgkQEMIGVCc8BjCM9ACggDOCCmp09Cooi8bpZ4TfQQIr ChwAn2zW47jeY7wjun8UEzWB2UgeYZhg =yQu+ -END PGP SIGNATURE- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Clipboard handling on Windows
On Fri, Dec 2, 2011 at 3:33 PM, Kohei Yoshida wrote:
> As a test, I
> wrote another quick program to retrieve the clipboard format info using
> the IDataObject API,
And here is the code (attached) that I used to retrieve the clipboard
format info via IDataObject, in case someone is curious.
Kohei
#include
#include
#include
using namespace std;
int main()
{
IDataObject* pData = NULL;
HRESULT hr = OleGetClipboard(&pData);
if (hr != S_OK)
{
cout << "failed to get the clipboard data object instance." << endl;
return EXIT_FAILURE;
}
cout << "IDataObject = " << pData << endl;
pData->AddRef();
IEnumFORMATETC* pFormats = NULL;
if (pData->EnumFormatEtc(DATADIR_GET, &pFormats) != S_OK)
{
cout << "failed to get available format types." << endl;
return EXIT_FAILURE;
}
pFormats->AddRef();
pFormats->Reset();
FORMATETC fetc;
while (S_FALSE != pFormats->Next(1, &fetc, NULL))
{
cout << "format code: " << fetc.cfFormat << endl;
char name[100];
int len = GetClipboardFormatName(fetc.cfFormat, name, 100);
if (!len)
continue;
cout << "format name: " << name << endl;
}
pFormats->Release();
pData->Release();
return EXIT_SUCCESS;
}
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Clipboard handling on Windows
Hi Tor, On Fri, 2011-12-02 at 20:24 +0200, Tor Lillqvist wrote: > > So, I'm still not understanding this fully. Why is it that, when you > > use the 2nd API, you only see some of the formats, not all? > > One possibility might be that the first API also returns "synthesized" > clipboard formats. Ah, that's definitely something to keep in mind. Thanks for the info. BTW, I was actually asking the wrong question. It wasn't true that the 2 APIs were returning different clipboard format sets. As a test, I wrote another quick program to retrieve the clipboard format info using the IDataObject API, and the code retrieves the same set of available format types as what the other API does. This means that the reason why we are getting far fewer clipboard formats must be somewhere in our own code. In fact, we do have a wrapper class for IDataObject (named CAPNDataObject) that does some sort of pre-filtering. I'll look into that class to see if it's doing something funny there. Thanks a lot everyone. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Clipboard handling on Windows
> So, I'm still not understanding this fully. Why is it that, when you
> use the 2nd API, you only see some of the formats, not all?
One possibility might be that the first API also returns "synthesized"
clipboard formats. For instance, if you put CF_UNICODETEXT format data
on the clipboard, Windows itself from that synthesizes when needed
also the CF_TEXT ("ANSI", i.e. current system codepage) format, and
advertises also that. See
http://msdn.microsoft.com/en-us/library/windows/desktop/ms649013%28v=vs.85%29.aspx#_win32_Synthesized_Clipboard_Formats
--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Clipboard handling on Windows
On Fri, 2011-12-02 at 11:52 -0500, Kohei Yoshida wrote: > Hi Noel, > > On Fri, 2011-12-02 at 18:40 +0200, Noel Grandin wrote: > > > 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. > > So, I'm still not understanding this fully. Why is it that, when you > use the 2nd API, you only see some of the formats, not all? I'm specifically referring to the fact that IDataObject's EnumFormatsEtc() methods returns far fewer formats than EnumClipboardFormats() function which is part of the Windows clipboard API. And sometimes we need to have access to the formats only returned by the latter. Very puzzling... Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Clipboard handling on Windows
Hi Noel, On Fri, 2011-12-02 at 18:40 +0200, Noel Grandin wrote: > 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. So, I'm still not understanding this fully. Why is it that, when you use the 2nd API, you only see some of the formats, not all? More importantly, if we want to have access to those formats that the 2nd API doesn't return, what are we to do? Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
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 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
