Example: When a cell filled with the number 200 is dragged on the edge to cells below in the column, these are filled with increments 201, 202 etc. This also happens when Tools > Autoinput is unchecked. Expected behaviour: The value 200 should appear in all the cells of the selection.
You can fill two cells, A1 and A2 with exp 200 select them and then drag them down and you will have in all cells the value 200 You can also ctrl+c select all cells you need and then ctrl+v Yes i can reproduce but still i think its the way drag and drop works Best regards
Thanks for the hint. IMHO, software should never change a value I entered when I did not instruct it to do so. Not being able to turn this 'feature' off - is clearly a bug.
Thank you for reporting the bug. I can confirm the bug present in Version: 6.4.0.0.alpha1+ (x86) Build ID: ec7374ff84c71edfbb30d6e4dc5b486b6df7107f CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-11-10_21:37:30 Locale: en-US (en_US); UI-Language: en-US Calc: threaded and in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
I don't think this has anything to do with autoinput. Autoinput is about suggesting words/entries from the same column when you start typing the first few characters in a cell, not about dragging and filling cells. This "incrementing numbers" behavior for draging and filling has always been like this in LibreOffice Calc, and I believe always been like this in MS Excel as well. I doubt changing it is a good idea, no matter it's intuitive or not. To fill the cells with the same numbers, you can start with two cells with the same numbers as comment 1 suggested, or hold Ctrl key when dragging. IMHO this is either NOTABUG or WONTFIX.
Ming Hua, ok, so then the title may be changed, the issue remains. If it was always like this, it was ALWAYSABUG ;-) In MS Excel, this has to be explicitly defined as a 'series': https://superuser.com/questions/841439/excel-auto-fill-a-column-with-increment Maybe for a reason.
Dear Burg, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Checked again with latest 7.3.0.3 - and the behaviour is unchanged. Ming Hua might be right that the developers do not consider this a bug but a feature, and instead of marking it "WONTFIX" decided to ignore it. For people new to spreadsheets this might be considered a feature, in order to start quickly with a new sheet. But on more complex sheets it can introduce some misunderstanding, because text and formulas are copied 1:1 but number data is silently incremented, not obvious at first sight. So maybe we change this bug to a feature request?: "Make auto-increment on copied numbers configurable"
Indeed, the default (i.e., without Ctrl pressed) behavior in e.g. Excel 2016, is to copy the single selected cell, not to auto-increment it. This is different to the default behavior (without Ctrl pressed) in the same Excel, when two or more cells are selected: then by default, it tries to analyze and continue. An (advanced?) configuration might be reasonable. A code pointer: one should check how nScFillModeMouseModifier (sc/inc/global.hxx) is set and used. The code of interest is in sc/source/core/data/table4.cxx; one might need to make the difference between the case when start and end row/columns is the same, vs. when it's different.