GNOME Bugzilla – Bug 143220
Operations on regions with hidden content
Last modified: 2018-05-22 13:06:39 UTC
Hi, I'll try to give an example: cols 1 2 3 rows 1 colors nr cars cost each 2 green 2 10.000 3 blue 4 15.000 4 yellow 1 25.000 5 green 10 30.000 6 black 7 7.000 then I select Auto Filter, so thar the first row is the title row. if I want to remove all the rows containing green cars, I would filter in the color column by green, which gives me: cols 1 2 3 rows 1 colors nr cars cost each 2 green 2 10.000 5 green 10 30.000 then I select rows 2 through 5 and delete them. I was expecting the result to be (as it is in Excel since version 97 as Dave told us): cols 1 2 3 rows 1 colors nr cars cost each 2 blue 4 15.000 3 yellow 1 25.000 4 black 7 7.000 the green lines would have disappearesd and a row renumbering proccess would have taken place. But in Gnumeric, instead, what I get is: cols 1 2 3 rows 1 colors nr cars cost each 2 black 7 7.000 All the rows between the firs and the last "green" ones were deleted. Which is: gnumeric removed not only the visible (green) but also what was not visible (rows containing blue and yellow cars).
I though I had reported it in March, but I can't find the report. This is a MUST in a spreadsheet.
If I "select rows 2 through 5 and delete them", I would expect rows 2 through 5 to be deleted. Apparently you are not happy with that. [Personally I could not care less that some other programs don't do what you ask of them.] If this weren't in an autofilter situation would you also expect hidden rows to remain after you deleted a section of spreadsheet?
Lowering prioritym fixing OS, etc.
Comment to comment #2 from Andreas Guelzow No, I'm not happy that gnumeric doesn't perform as it was supposed to. You say you don't care, probably you don't work with big spreadsheets, because if you did, you could see the difference. If it is because I refered Excel, I must say that probably you don't dislike Microsoft much more than I do. But Excel is still the benchmark. Otherwise prove I'm wrong.
Andreas : Having a distinction between filtered and hidden seems useful. I think this is a bug. This sort of operation is reasonably common. I suppose a user could do some sort of search then use alt-space to select the rows and try to delete (although we do not support discontinuous deletions either). We should support this. However, it is definitely not a 1.2 level change. The ins/del col/row code took a long time to handle all the vagaries. We'll try to work it in for 1.3.x
Wouldn't it be simpler (both from an implementation and an user interface point of view) to have a "Delete Visible"?
The implementation is the same either way. we need to add support for discontinuous col/row deletion. I like the notion of del vs del visible. The down sides are - ui gets kinda cluttered. There is already alot in that context menu - we'd loose some XL finger feel. This seems manageable if we make it really obvious.
I think that the 'del visible' should be the default option. If the other option is also possible, it would be nice, although I don't see any usefulness.
hmm we have not considered offering a 'del visible' the current choice was - delete all - delete unfiltered The latter != visible. In XL there is a marked difference between hiding a col/row manually and filtering them. The former will be deleted in this case the later will not.
So, Jody, are you saying that if I want to delete visible rows I have to filter them in the opposite way? The visible filter is not only useful for deleting but, for example, to paste values to a column. In the example given, suppose you want to fill in a fourth column with type of fuel used. You could right in a cell 'diesel' then copy it, filter the list for all green and black cars and then paste the contents of that cell to the fourth column in the filtered rows. I would expect not to fill the 4th col of other rows with 'diesel'. As it is right now, Gnumeric will do such, which is very complicated for a user dealing with large sheets.
sorry, correction: instead of right it is write
*** Bug 149824 has been marked as a duplicate of this bug. ***
*** Bug 315853 has been marked as a duplicate of this bug. ***
This is a very annoying bug, and it is also very difficult to understand what's wrong when you don't know about it. So I'm a bit surprised to see that 6 years after the bug has been reported, it's still not fixed. Is it worked on? Or does nobody care?
This is one of the few real deficiencies in Gnumeric. The priority of Normal is far too low, and it is NOT an enhancement. It is a prominent feature which was never implemented properly.
Julien, Kevin, Am I correct in assuming that you are working on a patch for this? (Personally I rather fix bugs that I think are indeed bugs.) And clearly something that doesn't exist in Gnumeric can't be a prominent feature of Gnumeric. He request of making it a feature is clearly an enhancement.
I'm only a user, sorry. If I could contribute some other way (such as financially) to solving this problem, I happily would. I was just trying to increase the emphasis on a deficiency which has been around for a long time. There are several duplicates, but the problem is that the filter (which is what I meant by a feature) just isn't useful. If you can't copy or delete or restrict the application of a function to the filtered values, the the filter is effectively useless. It's too bad as otherwise gnumeric is far and away my favorite spreadsheet, and I use it every day for my work.
Note that the SUBTOTAL function ignores the filtered-out rows. There are very few people that currently write code for Gnumeric. So obviously fixes and enhancements affected those people take precedence. And none of them seems to be concerned about this deficiency.
Andreas, you are wrong in assuming that I am working on a patch for this bug. Bugzilla is a bug reporting system and I'm only doing what I am supposed to do with it: describing bugs, and making sure the developers are aware of them. As for fixing the bug, I've got already enough work with fixing the bugs reported by the users of my own applications, because the lazy users don't seem to want to fix them themselves :)
Julien, the original report was an enhancement request. Your comment (comment #14) did not add anything to that request (except that it could be read as an insult).
Well, it was certainly not an insult. I was just expressing my surprise, seeing how it seems to me to be a real showstopper (and certainly not an enhancement), and that no work seems to be done on it (which, by itself, is understandable if no developer cares about this bug). The goal of my comment was only to try to get some attention to a (major) bug that seemed to have been ignored by the developers.
Ditto from me. There appears to be a difference of opinion due to differing perspectives. In the opinion of the developers, the filter is complete and enhancements are being requested. In the opinion of users, the feature is incomplete as it is not usable. I just want to give a user's perspective as this deficiency is a major problem for us, and it needs to be addressed.
I believe that the actions that should optionally avoid acting on rows that are filtered out are: 1) clearing [Can be restricted to filtered rows in 1.10.8 and later] 2) deleting 3) copying 4) counting, adding, etc. [Can be done using SUBTOTAL, but requires manual recalc] Are there any others that you find desirable?
Thanks Andreas, those are the major ones. Statistical functions (st dev etc) would also be useful. It would also be useful if the filtered out values weren't graphed, but this may open another can of worms.
the statistical functions need to be Excel and/or OpenFormula compatible. There are no provisions in the OpenFormula draft standard to exclude any hidden or filtered out rows. So to provide for that a different mechanism than changing the formula behaviour would need to be used. Note though that the subtotal function provides for some of the statistcal functions: 1 AVERAGE 2 COUNT 3 COUNTA 4 MAX 5 MIN 6 PRODUCT 7 STDEV 8 STDEVP 9 SUM 10 VAR 11 VARP Charting is a completely different issue.
That's fine - the subtotal is perfectly usable. The most important functions are the ones you identified, especially the copy/delete. Thanks.
*** Bug 642532 has been marked as a duplicate of this bug. ***
*** Bug 645970 has been marked as a duplicate of this bug. ***
*** Bug 669912 has been marked as a duplicate of this bug. ***
*** Bug 685488 has been marked as a duplicate of this bug. ***
Created attachment 232246 [details] [review] An attempt to implement 'Copy Visible' I didn't add an entry to context menu, only to main 'Edit'. Keyboard shortcut is 'shift-control-C'. Xclipboard will have only visible cells. gnumeric range still keeps empty rows/cols for hidden cells. If cells contain formulas referring to hidden cells, result of pasting will have incorrect calculations.
I am also highly interested in being able to copy/paste only the visible rows. Valek seems to have sent in a proposal to fix in 2012. I can not yet find these options in gnumeric. Will the fix he sent be implemented? It seems to feature an option to only Copy the items that are Visible, which would be a very practical feature.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnumeric/issues/25.