Description: Tracking changes creates an entry for every change (so pasting a column means an entry for every cell) Steps to Reproduce: 1. Open attachment 161647 [details] 2. Edit -> track changes -> record 3. Copy column A-C and paste at EFG 4. Edit -> Track and changes -> Manage Actual Results: Every cell has it own entry in tracking changes Expected Results: Paste seen as a single action, similar to undo. However Excel does this too.. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: 006c65bbd472cb1d7d44e095714e28190b76be0d CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
I really have no clue how this should work. From performance point of view I would opt for a single entry, instead of every cell. Dialog 'manage' opens quite slow because of the long list of entry's And when inserting/deleting a row it's only one entry, too.. OTOH, this is bit of an abuse of the tracking change feature.. So not a bug.. or a reason to make it a single entry
In Writer, pasting a whole table is one entry while a column is split into cells. With Calc it's always a per-cell TC. I agree that copy/paste actions should be considered as a whole for TC as done with the undo stack.
No, it shouldn't. Or rather, it could in this one special case only if the target range was empty. As soon as existing data is replaced by the paste at least those individual values and changes must be tracked. So while splitting the paste into blocks of empty and non-empty target ranges might be a solution, tracking the empty target blocks would yield just a "here is a block of pasted data". If those then before empty cells contained data before which was cleared before pasting, going back in history to pick an older value would have to split that one block again. Same if a value in a pasted range is changed later. While all this may be doable it would quite complicate the tracking and the dependencies of changes.
(In reply to Eike Rathke from comment #3) > No, it shouldn't. Or rather, it could in this one special case only if the > target range was empty. As soon as existing data is replaced by the paste at > least those individual values and changes must be tracked. So while > splitting the paste into blocks of empty and non-empty target ranges might > be a solution, tracking the empty target blocks would yield just a "here is > a block of pasted data". If those then before empty cells contained data > before which was cleared before pasting, going back in history to pick an > older value would have to split that one block again. Same if a value in a > pasted range is changed later. While all this may be doable it would quite > complicate the tracking and the dependencies of changes. Valid point.. FWIW.. excel does the same thing.. so not even sure if this 'broken' .. maybe the perf side of this should be tackled... someday
Note I'm not against such a change, just to state that it's not as simple as it may look from first glance. It probably would also be needed to introduce such new feature to ODF and older releases wouldn't be able to read it. And it couldn't be exported to Excel..
(In reply to Eike Rathke from comment #3) > No, it shouldn't. What a pity. So let's resolve as WF.
(In reply to Heiko Tietze from comment #6) Not sure if this fully in line with Eike his comment.. "Or rather, it could in this one special case only if the target range was empty." OTOH a lot of effort, for something trivial..