Description: The .uno:Copy command called by the recorded macro doesn't work correctly. The requirement is to copy the format only, between two ranges. If the clipboard contains nothing (situation at work session opening), the .uno:Copy command does nothing. If the clipboard was actually given a contents, then the copied format comes from that contents, not from the source range as declared in the program. The attached example shows the problem. As this is the only way to programmatically "paste special formats only" (no API available, AFAIK), this functionality should be restored. Steps to Reproduce: See attachment Actual Results: The copied format is the one pertaining to the clipboard contents. Expected Results: The copied format should be the one belonging to the source range. Reproducible: Always User Profile Reset: No Additional Info: Problem present in LibreOffice v.7.3.6 (LinuxMint 20.3 Cinnamon) and found to be present in LibreOffice v.7.5 (Windows). Dunno about former versions.
Created attachment 185316 [details] ODS file for tests purposes
Reproduced in the following sequence of actions. 1. Open the attached file in LO 2. We copy any text in the Firefox application to the clipboard. 3. Click on the "Copy v1" button on the sheet of the open Calc document. See also: https://ask.libreoffice.org/t/uno-copy-doesnt-copy-a-given-range-but-uses-the-clipboard-contents/87860?u=sokol92. 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: en-US Calc: CL
IMO, not a bug. 1. The problem is that clicking the button moves the *focus* to the button. This can be seen, if you put a breakpoint to the code after .uno:Copy, before selecting the target range. Clicking the button then would stop after the .uno:Copy execution, and you can inspect the state of the spreadsheet at this point. You will see, that despite the *selection* is on the source range, the *focus* is on the button (on Windows, it's shown by dotted frame around the button text). The "Cut"/"Copy"/"Paste" toolbar buttons will be disabled; this shows that .uno:Copy would do nothing in this situation. 2. This is caused by the "Take focus on click" property of the pushbuttons.
The button has the "Take focus on click" property True by default. Accordingly, somewhere (in the documentation?) it is necessary to warn the programmer: If there is a non-zero probability of working with the clipboard (copy to clipboard) from a macro launched by a button, be sure to change the button "Take focus on click" property to False. From my point of view, this is very important.
(In reply to Mike Kaganski from comment #3) > IMO, not a bug. Objection! > > 1. The problem is that clicking the button moves the *focus* to the button. > This can be seen, if you put a breakpoint to the code after .uno:Copy, > before selecting the target range. Clicking the button then would stop after > the .uno:Copy execution, and you can inspect the state of the spreadsheet at > this point. You will see, that despite the *selection* is on the source > range, the *focus* is on the button (on Windows, it's shown by dotted frame > around the button text). The "Cut"/"Copy"/"Paste" toolbar buttons will be > disabled; this shows that .uno:Copy would do nothing in this situation. > > 2. This is caused by the "Take focus on click" property of the pushbuttons. 1. The .uno.Copy command can (should) never be expected to "copy" a button except the containing document is in FormDesignMode. 2. Generally the .uno.Copy disregards the focus but works with the CurrentSelection. A living control can have the focus but can't be selected. Note: If a CellRange is selected there can be an additional cell having the focus but not being selected. This focus cell will then be ignored by .uno:Copy . 3. IF the control were copied, what should .uno:InsertContents paste then? Nothing because a control hasn't any cell attributes. And this is what actually happens if the first .uno:GotoCell (funny name) is commented out while an ordinary shape is selected. 4. There are more inconsistencies in the context. Is the slot machine actually maintained and does it get bug fixes?
(In reply to Wolfgang Jäger from comment #5) > 4. There are more inconsistencies in the context. Is the slot machine > actually maintained and does it get bug fixes? Yes. I haven't closed the bug (which I would do if I were sure :)), and added the IMO. So indeed, this is subject to discussion and change if needed. I have no strong feelings either way.