https://bugs.freedesktop.org/show_bug.cgi?id=62436
tmacalp <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] See Also| |https://bugs.freedesktop.or | |g/show_bug.cgi?id=42535 --- Comment #2 from tmacalp <[email protected]> --- Interesting. I can confirm this still affects LO 4.2.1.1 under Windows 32bit. It looks even more general than what you've described. It appears that whenever you paste, your next action's range is checked from cell A1 instead of the actual cursor position. My test: 1. Start a new spreadsheet 2. Insert a number in A10 3. Select any cell (C15 in this case) 4. Copy (Ctrl-C) 5. Paste into same cell (Ctrl-V) 6. Ctrl-down You'll notice that your cell will cursor down the exact same number of cells it takes to go from A1 to your number in A10, leaving the cursor in C24. This also works going horizontal... 1. Start a new spreadsheet 2. Insert a number in D1 3. Select any cell (C15 in this case) 4. Copy (Ctrl-C) 5. Paste into same cell (Ctrl-V) 6. Ctrl-right Your cursor will travel to the right the same number of cells from A1 to D1 to end up in F15. Because it's based on a faulty cursor check based on cell A1, this behavior should only be reproducible for cells in column A or in row 1. Otherwise, it will jump to the end of the range as expected. This faulty/unexpected behavior doesn't really inconvenience you unless you are actually selecting cells (ctrl-shift-arrow) as described in bug 42535, which appears to be related. I'll add that bug as a "See Also." -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
