Description: According to the help facility file:///C:/Program%20Files/LibreOffice/help/en-GB/text/scalc/guide/cellcopy.html?DbPAR=CALC#bm_id3150440 viz Cells were hidden using the Hide command in the context menu of the row or column headers, or through an outline. Copy, delete, move, or format a selection of currently visible cells. All cells of the selection, including the hidden cells, are copied, deleted, moved, or formatted. However, drag to copy and increment a matrix including the hidden cells/column fails to copy the hidden cells. Also, if the missing value is inserted after the column has been exposed and then a number of rows are hidden and the original column re-hidden then the incrementation continues sequentially from the complete rows AFTER the hidden rows without incrementation for the hidden cells Steps to Reproduce: insert the number 1 into C3 Select and drag to fill four cells upto and including F3 Create formula SUM(C3:F3) in cell G3 Note the result is 10 Select and Hide column D utilising the context menu Select the range C3:G3 Drag to fill the matrix C4:G7 Note the results in Column G Select Columns C>E and unhide from the column context menu Note the missing values for the previously hidden cells D4>D7 Note Also the columnar increment allows for the hidden cells D4>D7 Now add the missing value "6" to D7 Hide rows 8>11 and column D Select the C3:G3 matrix again and drag to increment C13:G15 Unhide all rows and columns Note the missing row increments and also that the missing rows are not incrementally adjusted by +5 at row 12 but by +1 Significant contradiction in the incrementation methodology between missing rows and columns Actual Results: Test 1: The contents of Cells D4>D7 are blank and the subsequent columns are incremented as though the blank cells had correctly incremented Test 2: The contents of rows 8>11 are blank and the incrementation continues from row 12 but unincremented for the hidden rows Expected Results: Test 1: D4>D7 should have incremented to 6 Test 2: Rows 8>11 should have incremented with rows 12>15 also incremented from row 11 results Workaround - Select the column and set the width to an "invisible" value perhaps 0.01cm Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Version: 6.4.6.2 (x64) Build ID: 0ce51a4fd21bff07a5c061082cc82c5ed232f115 CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: default; VCL: win; Locale: sv-SE (en_GB); UI-Language: en-GB Calc: threaded
In the 2nd test I inadvertently advised to select the entire matrix starting at C3:G3 to create the new matrix to C15:G15. Of couse it's only necessary to select the last complete line of the original matric C7:G7. Eating Umble Pie.
Reproduced NixOS Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 67e47070a7580a17804adce812cc2f98bfe7b51f CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: x11 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded
Bibisected with Linux 43all repo to range ee7084c4f720c932df67c8ff033dab4d8d556179..250feedd8e50e5eb52682a194823567ba5287c60 Out of which these seem relevant: commit 73ff3a49a0891c7787f08eec86357c320a76c263 Author: Markus Mohrhard <markus.mohrhard@googlemail.com> Date: Wed Apr 11 22:02:06 2012 +0200 first part for ScTable::GetAutoFillPreview Actually this is a bit more tricky. Currently it is showing wrong values for hidden rows/columns commit 290a851bdc42a78426dea987ffbcb511e36c34fb Author: Markus Mohrhard <markus.mohrhard@googlemail.com> Date: Wed Apr 11 21:53:30 2012 +0200 ScTable::FillAuto should work with hidden rows/columsn now too commit a6a0ea2f352f98b801bb6aade04caeb07e180403 Author: Markus Mohrhard <markus.mohrhard@googlemail.com> Date: Wed Apr 11 21:44:09 2012 +0200 add unit test for autofill commit f61cbce529d039bb0e208e81cf66974cc4428420 Author: Markus Mohrhard <markus.mohrhard@googlemail.com> Date: Wed Apr 11 21:35:59 2012 +0200 make ScTable::FillSeries work correctly with hidden rows/columns There was one intermediate state, where the cells were filled, but not incremented (I marked it as 'good').
I would consider autofill affecting hidden rows as a bug it if were to happen. It very intentionally does not work that way. See bug 113785.
bug 56799 is discussing autofill - seems to be identical to this discussion. Note the last comment 21 - NOTABUG. *** This bug has been marked as a duplicate of bug 56799 ***
(In reply to Justin L from comment #4) > I would consider autofill affecting hidden rows as a bug it if were to > happen. It very intentionally does not work that way. See bug 113785. Are you implying you'd sooner rewrite the help facility than fix the bug? At the very least, a well-defined procedure would probably give the user the ability to select a preferred approach. Just like when the user is asked if they would prefer cell references to be expanded and adjusted when cells/rows are inserted or autofilters re-sort the cells according to value..............and many more examples which any user could identify. Reductio ad absurdum. I imagine there is some mechanism with LO that detects "drag Filling" and presumably that mechanism could be improved to incorporate "would you like the hidden cells updated?"
Reproduced ; not only with Hide feature but also with Group feature Version: 25.2.5.2 (X86_64) / LibreOffice Community Build ID: 03d19516eb2e1dd5d4ccd751a0d6f35f35e08022 CPU threads: 2; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded 1) is Hide and Group supposed to work the same, except for the obvious visual appearance (handles "+"/"-"..) ? 2) I agree that this needs to be fixed. I use Grouping mostly just because there are too many rows/ cols of same type (ex, hundreds of them!) and need to hide out of the way, but this does not mean autofill (either double click or drag the corner ) should not work on them. Proposed workaround (setting the width/height of cells to be 0.00..1) is very cumbersome. Apparently, some people like the current behaviour. Options for fixing: o1. Have 2 distinct kinds of grouping or hiding: independently accessible - one for hiding from view only; but autofill still works on them - one for hiding from calculations, Maybe Grouping - for hide out of view, and Hiding - for hiding from calculations? o2. Pop-up a dialog at autofill to ask user whether to also work with the hidden rows/cells o3. Allow a preference option for the user to choose one vs other behaviour.
(In reply to vic from comment #7) > Options for fixing: > > o1. Have 2 distinct kinds of grouping or hiding: independently accessible > - one for hiding from view only; but autofill still works on them > - one for hiding from calculations, > > Maybe Grouping - for hide out of view, and Hiding - for hiding from > calculations? > > o2. Pop-up a dialog at autofill to ask user whether to also work with the > hidden rows/cells > > o3. Allow a preference option for the user to choose one vs other behaviour. 04 Dramatically improve Tables to emulate Excel and Google Sheets dynamism with any entry in a contiguous row automatically replicating table functions regardless of the hidden or grouped status of any part of the table. Functions are reproduced, manual entries are left as - would you believe it? Manual entries. Any added contiguous columns are then defined by the user and if it's a formula - replicated, if it's data entry - data entry.
(In reply to Colin from comment #8) > 04 Dramatically improve Tables to emulate Excel and Google Sheets dynamism > with any entry in a contiguous row automatically replicating table functions > regardless of the hidden or grouped status of any part of the table. > Functions are reproduced, manual entries are left as - would you believe it? > Manual entries. Any added contiguous columns are then defined by the user > and if it's a formula - replicated, if it's data entry - data entry. I'm not (yet) familiar with this "Tables" concept, but it sounds interesting. Why would we need the whole of spreadsheet for? I guess Your whole "app" could be constructing as an interraction of several tables. Reminds me of Numbers of Apple https://en.wikipedia.org/wiki/Numbers_(spreadsheet) > Numbers uses a free-form "canvas" approach that demotes tables to one of many different media types placed on a page. Other media, like charts, graphics, and text, are treated as peers. If you know a free app that is exclusively based on such "tables", please let me know. Anyway, hidden rows should not be ignored :)
(In reply to vic from comment #9) > (In reply to Colin from comment #8) > If you know a free app that is exclusively based on such "tables", please > let me know. Google Sheets has "recently" introduced their own "take" on Excel tables with some very interesting variations of Excel pivot table functionality, visualised directly on the sheet rather than having to define a new pivot table in a dedicated location. And file sharing in GDrive is excellent. Happy to help if you need some simple examples. > Anyway, hidden rows should not be ignored :) I know I don't need to indicate 120% support for this statement Feel free to hide my comments on Google as irrelevant to the main theme and DM if desired
*** This bug has been marked as a duplicate of bug 85170 ***