After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 149824 - gnumeric copies hidden rows and columns
gnumeric copies hidden rows and columns
Status: RESOLVED DUPLICATE of bug 143220
Product: Gnumeric
Classification: Applications
Component: General
git master
Other All
: Low enhancement
: ---
Assigned To: Jody Goldberg
Jody Goldberg
: 344285 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-08-10 16:40 UTC by Benjamin Kahn
Modified: 2008-09-11 01:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Benjamin Kahn 2004-08-10 16:40:57 UTC
1. enter the rows: 1 2 3 4 5
2. hide the 3rd row
3. select all 4 rows left
4. Hit copy
5. Select A8
6. Hit paste

All 5 rows are copied when only 4 should have been.
Comment 1 Andreas J. Guelzow 2004-08-10 21:29:11 UTC
Why do you think only 4 should have been copied? Since the hidden rows may
contain important formulas that make the lower rows work I would expect them to
be copied too!
Comment 2 Morten Welinder 2004-08-11 15:09:57 UTC
I would guess that this is a case where sometimes you want one thing and sometimes
the other.  Ugh.
Comment 3 Jody Goldberg 2004-08-11 16:22:15 UTC
XL is not at all consistent in it's handling of hidden cols/rows
Some times only rows hidden by filters are ignored.  We're most likely back to
our 'copy visible' idea at the ui level to handle this smoothly.
Comment 4 Benjamin Kahn 2004-08-11 17:53:30 UTC
Okay.  Let's simpify the problem somewhat:

If you are pasting text/plain or text/html, it should only copy the visible rows.

If you are pasting simple data (no pasting values that are referenced in hidden
rows that would otherwise be included in the selection), it should only copy the
visible rows.

If you are copying data which includes hidden rows that supply values for
formulas for visible rows, the formulas should point to the old rows and it
should only copy the visible rows.

After that things get tricky.  What happens for cut?  (Do the hidden rows get
removed too?  If so, the formula can't refer back to them.  If not, won't that
do weird things to the spreadsheet data and cause hard to debug problems?) 
Other problems?
Comment 5 Andreas J. Guelzow 2004-08-19 05:06:21 UTC
"If you are copying data which includes hidden rows that supply values for
formulas for visible rows, the formulas should point to the old rows and it
should only copy the visible rows."

Doesn't work reasonably:

A1: 1 
A2: 3 
A3: =sum(A1:A2)  (hidden row)
A4: =A3/2

Suppose A1:A4 is selected and pasted to B8. Then clearly B11 should contain
=B10/2 which contradicts that statement.

Comment 6 jensflorian 2004-09-01 07:18:50 UTC
There are also other inconsistences. Assume I enable the Auto Filter option to
display only rows with the value I want. Now I mark these rows, the sum and
count values at the bottom status line do still display the values consiting of
visible AND hidden data. Now copying the data gives me the same problem our
first reporter has - all data is copied, but I want only the marked data copied.
This is the behavior I want - if I want the hidden rows copied as well, I would
unhide them prior to copying.

Note that M$ Excel behaves here differently from gnumeric - it counts and copies
only the visible data.
Comment 7 Jody Goldberg 2005-01-14 04:26:42 UTC
After some consideration it seems like the cleanest solution is to add a 'copy
visible' operation.  Can anyone see a reason to provide a 'Cut visible' too ?

I suppose we'll have to support XL's filtered row support too, but that's damn
ugly. 
Comment 8 Jon Kåre Hellan 2006-10-17 11:10:16 UTC
*** Bug 344285 has been marked as a duplicate of this bug. ***
Comment 9 Jérôme Guelfucci 2007-11-08 18:20:49 UTC
Ubuntu bug for this : https://bugs.launchpad.net/ubuntu/+source/gnumeric/+bug/160966

With gnumeric 1.7.8 and 1.7.11
Comment 10 Morten Welinder 2008-09-11 01:03:17 UTC

*** This bug has been marked as a duplicate of 143220 ***