Description: Hello, I have had this issue since years. I did not find the correct answer in the LO forums to this issue. And also the issue as described below might be more detailed than the previous ones or apparently (but not) similar ones. On LO on Windows it is absolutely impossible to copy-paste an image from the clipboard into any LO document, WHEN the image is not the very last (recent) thing that has been copied… I can copy-paste ANY text from the windows clipboard even if it was very old and at the end of the clipboard queue. But this is not working for any screenshot that is not the very last (recent) thing listed on the clipboard. The very last screenshot is still copy-past’able’ into LO documents. But as soon as I copy let’s says a word and when I go to the Windows clipboard with pressing the Windows Icone + V, if I select the visible screenshot that is on position 2 or 3 etc… but not in position #1, then pasting the Screenshot into any LO document would never work. It works with ANY other software but not at all with LO. And this issue has been the same for at least 3-4 years. And believe me I have hoped at each new release of LO that this issue would be solved but the issue is STILL there. When I click to copy an image and then copy text and then try to paste the copied (not screenshooted) image from the clipboard the issue is the same. Also, when using the Print Screen key, the issue is the also the same: basically the issue is about all images whatever the way they were copied and added in the clipboard, when listed 2nd or more in the windows clipboard queue. Note: I tried obviously on other PCs and the issue is there too… This issue relates to all main LO components: Impress, Writer, Calc Steps to Reproduce: 1.Take a screenshot or copy an image into the Windows clipboard 2. Copy some text (not an image) into the clipboard 3. Try to paste the image which is second in the queue of the windows clipboard into any LO component ==> it will not work Actual Results: Impossible to paste any image from the windows clipboard into any LO component, when the given image is not the very last thing that has been copied into the clipboard Expected Results: Being able to paste an image copied into the windows clipboard into LO components even if this image was the last before the last that has been copied into the windows clipboard Reproducible: Always User Profile Reset: No Additional Info: Thank you and good luck for resolving this bug. Great gratitude towards the overall community of developers and people who work and have been working so long to develop Libre Office!
Repro. Version: 7.4.2.3 (x64) / LibreOffice Community Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf CPU threads: 6; OS: Windows 10.0 Build 19044; UI render: default; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: CL
When pasting an older using Windows' Clipboard history manager (WinLogo+V), the clipboard contents is replaced with the following three item types (seen with NirSoft' InsideClipboard): name size CF_BITMAP (id=2) 0 ExcludeClipboardContentFromMonitorProcessing 90 ClipboardHistoryItemId 76 The second is likely internal, to avoid capturing it second time, so uninteresting. OTOH, [Print Screen] button puts these to the clipboard: name size CF_BITMAP (id=2) 0 CF_DIB 8 294 452 CF_DIBV5 8 294 452 The interesting work happens in CDOTransferable::getClipboardData, which is called to obtain a bitmap, and requests a CF_DIB. We could consider a fallback to also request CF_BITMAP when DIB fails, but - read below. Also, it tries to obtain the data from the IDataObject. It needs a proper tymed; and in this specific case, the tymed that works is TYMED_GDI, so we could try to fallback to it, but - read below. Now for funny things. Even when implementing these ideas, the paste would fail, because WinBITMAPToOOBMP (that is called eventually for CF_BITMAP) would fail in a call to GetDIBits (after a "succeeded" call to GetBitmapDimensionEx, which gave [0, 0] size). OK, we can replace GetBitmapDimensionEx with GetObjectW(aHBMP, sizeof(BITMAP), &aBITMAP), giving the correct info ... but GetDIBits will fail anyway with GetLastInfo() giving 87 (the parameter is incorrect). But the best thing here is the Microsoft documentation for "Clipboard Formats" [1]. It tells in Synthesized Clipboard Formats: > The system implicitly converts data between certain clipboard formats: if a > window requests data in a format that is not on the clipboard, the system > converts an available format to the requested format. > ... > Clipboard Format Conversion Format > CF_BITMAP CF_DIB > ... > When copying bitmaps, it is best to place the CF_DIB or CF_DIBV5 format on the > clipboard. This is because the colors in a device-dependent bitmap (CF_BITMAP) > are relative to the system palette, which may change before the bitmap is pasted. > ... > If you place the CF_BITMAP format on the clipboard (and not CF_DIB), the system > renders the CF_DIB or CF_DIBV5 clipboard format as soon as the clipboard is > closed. This ensures that the correct palette is used to generate the DIB. So many things *not* happening as documented, when using the MS tool named "Clipboard history"! They do not put CF_DIB to the clipboard (even though the original clipboard content included that); the system does not create a CF_DIB at the time they put the CF_BITMAP to the clipboard; and they do not create it even when asked for this format explicitly. And finally, they refuse to create a DIB from the HBITMAP, using the API. If someone intends to work on this, the proper way seems to be like what is used in WinSalBitmap::ImplCopyDIBOrDDB - use the HBITMAP to draw to our buffer, and then maybe output the bitmap to DIB using WriteDIBBitmapEx (vcl/dibtools.hxx)? [1] https://learn.microsoft.com/en-us/windows/win32/dataxchg/clipboard-formats#synthesized-clipboard-formats