https://bugs.documentfoundation.org/show_bug.cgi?id=153546
--- Comment #5 from Wolfgang Jäger <[email protected]> --- (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? -- You are receiving this mail because: You are the assignee for the bug.
