1. Type SN; 1; 2; 3; 4 in a column. 2. Type "=row(a2)" in A2. 3. Double-click the fill handle of A2. Problem: The formula does not get filled down from A2 to A5 like it would in Excel. Use-case: I have data in a standard format, but my last column of data has blank cells, and I inserted a new column on the right with a formula for all rows of data (the first time I need to select the range), then I edited the formula and try to double-click the fill handle, but it does not fill the entire range as expected. Workaround: I have to type Shift-Ctrl-Down, Ctrl-D
I just went through the steps to re-produce, The behavior works as expected - when I double click the cell handle the range fills. I am on LibreOffice 4.1.0.4 on Linux(Fedora 19) Perhaps this is unique to your platform, could you please enter in your LibreOffice Version and Operating System so a tester on your platform(if different than mine) can test it. As it is now, I don't know what platform/version you are on, so I am changing the bug status to NEEDINFO
Thanks for the response. I don't have my computer at the moment, but it was running the latest version of LibreOffice as at 1 Jul 2013 (I can't remember which version) and on Windows XP SP3. Just to be sure, I really mean cell A2 in step 2, the one that was at that point filled with "1", so after the three steps I should see SN; 2; 3; 4; 5 in one column.
Changing the bug status back to new (platform/version was already added previously). Also, to clarify, these are the steps again: Start with a blank worksheet Enter "b" in A1. Enter "a" in A2. Enter "a" in A3. Select A1 and double-click the fill handle. -- Does not fill "b" in the range A1-A3. -- Enter "b" in B1. Select A1 and double-click the fill handle. -- Still does not fill "a" in the range A1-A3. -- Select B1 and double-click the fill handle. -- Fills "b" in the range B1-B3 correctly. -- Select A1 and double-click the fill handle. -- Fills "b" in the range A1-A3 correctly. --
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-18
(In reply to p199999991 from comment #3) > Changing the bug status back to new (platform/version was already added > previously). Also, to clarify, these are the steps again: > Start with a blank worksheet > Enter "b" in A1. > Enter "a" in A2. > Enter "a" in A3. > Select A1 and double-click the fill handle. > -- Does not fill "b" in the range A1-A3. -- > Enter "b" in B1. > Select A1 and double-click the fill handle. > -- Still does not fill "a" in the range A1-A3. -- > Select B1 and double-click the fill handle. > -- Fills "b" in the range B1-B3 correctly. -- > Select A1 and double-click the fill handle. > -- Fills "b" in the range A1-A3 correctly. -- Reproduced. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 437210d58f32177ef1829d704f7f4d2f1bbfbfdd TinderBox: Win-x86@39, Branch:master, Time: 2015-06-18_07:21:56 Locale: fi-FI (fi_FI)
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
still repro steps from comment 3 Version: 6.2.0.0.alpha0+ Build ID: c4c56de1b0e62ec866b519b2b24c5e805f0a86d3 CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk3;
Not a bug. A double click on the auto fill handle should never overwrite existing data. See also bug 108209.
Sorry, I think the one who closed this bug didn't get the point of this bug report, and also missed the purpose of the fill handle that has always work that way in many other spreadsheet software. I, and many others, have always been using the fill handle in Excel to overwrite data below the cell. Say we have a formula in one of the columns in a huge spreadsheet that have already been previously dragged down to fill the rows. Now if we want to change that formula we just change it in the first record, and double-click the fill-handle. (Instead of the many more keyboard presses and shortcuts that we will need to execute.) Please read the instructions in comment 3 and reproduce the bug. The bug is about the inconsistency of this behaviour. The correct behaviour, that you will see in Excel, is that all the records get filled with the formula in the first record. It is a standard behaviour.
Sorry about my tone in the beginning of my previous post. I think I have wrongly assumed that Eike didn't correct the inconsistent behaviour, and that the observations in comment 3 would still be exactly the same (that's why I was annoyed). Actually he might have made it such that the last step in comment 3 doesn't even "fill correctly" (according to me). Still, I disagree with the change in bug 108209, assuming I understand it correctly.
(In reply to p199999991 from comment #9) > Sorry, I think the one who closed this bug didn't get the point of this bug > report, and also missed the purpose of the fill handle that has always work > that way in many other spreadsheet software. I, and many others, have always > been using the fill handle in Excel to overwrite data below the cell. > > Say we have a formula in one of the columns in a huge spreadsheet that have > already been previously dragged down to fill the rows. Now if we want to > change that formula we just change it in the first record, and double-click > the fill-handle. (Instead of the many more keyboard presses and shortcuts > that we will need to execute.) > > Please read the instructions in comment 3 and reproduce the bug. The bug is > about the inconsistency of this behaviour. The correct behaviour, that you > will see in Excel, is that all the records get filled with the formula in > the first record. It is a standard behaviour. I just tested with Excel 365 and it does NOT overwrite a cell with existing content, when double-click autofilling. It stops before that cell.
I too have tried Microsoft Office Excel online (I don't have a Windows machine right now) and it's doing what I expected, overwriting the cells when double-clicking the fill-handle. Did you try just typing "a", then below it "b", and below it "c", and then clicking "a" and double-clicking the fill-handle? It will certainly overwrite the "b" and "c" with "a"s.
In fact, there is a tutorial on this functionality at https://youtu.be/3L5DTFQEOP4?t=43 . Also, this tells us that the feature that I'm expecting also works on Excel 2013.
Apologies: I mixed this up with bug 108209. The behaviour of Excel matches LibreOffice in the case of bug 108209 now after the fix. When you have a empty cells between the cell data in A column and cells with contents in B column, Excel only fills the empty cells. If there are no empty cells inbetween, Excel fills while overwriting.
Created attachment 152499 [details] Simple test What we have here: - this is a RFE, that was never evaluated from UX, so I add it; - p199999991 himself wrongly set to New and twice Reopened, so I set back to Unconfirmed; - distinguished Eike wrote that this should not be accepted; - MSO behaves as requested here, overwriting if there are no empty cells in between (tested with MSO 2016); - this bug is not opposite to Bug 108209; - an option should be considered to determine behavior, so that overwriting is possible, not as default; - even if this is accepted it should be low/lowest priority enhancement. p199999991, you are advised NOT to change the status anymore.
Created attachment 152537 [details] fill-down behaviour of the fill-handle
I am not running Windows and can't test the daily builds, but from what I understand, bug 108209 causes the fill-handle to no longer work in the following case: 1. Type 1; 2; 3 in A1 to A3 2. Type =A1 in B1 3. Fill down from B1 to B3 4. Type =A1+1 in B1 5. Double-click the fill-handle in B1 Expected result: The new formula in B1 fills down to B3.
p199999991, your comment is not helpful, it's just repeating. I'll hide.
As Eike states comment 8, no overwrite of existing data (non-empty cells) by double-click auto-fill handle, which was issue of bug 108209. The safer usage--as implemented OOo--is to require *clear* (with <Del>) of the cell content after its selection. And only then allow auto-fill handle double-click action--use case requiring one extra step but assuring data integrity. IMHO alternative option is not a needed enhancement => WF
(In reply to p199999991 from comment #9) > missed the purpose of the fill handle that has always work > that way in many other spreadsheet software. "many other"? Which except Excel?
What I'm missing here so far is a clear definition of the circumstances/cases when to overwrite content and when not. Specifically if two or more columns are selected and not all columns have yet content immediately below the selection. Should an overwriting fill be started or not? And how far should be filled, e.g. should the fill stop at the first blank cell anywhere in a row of the selected columns, or should it continue if one of the adjacent cells in the selected columns does have content? The non-overwriting fill (all cells immediately below the selection are blank) is guided by the column immediately left (or right if no data there) and stops if that has no content; what would be expected of an overwriting fill? Stop there as well? Or continue to fill until all data in all selected columns end? Or continue to fill until data in one of the selected columns ends? Apart from that, I'm not a friend of overwriting data by just double clicking a handle of a selection. Twitching finger and boom..
(In reply to Timur from comment #15) > - distinguished Eike wrote that this should not be accepted; +1 > - MSO behaves as requested here, overwriting if there are no empty cells in > between (tested with MSO 2016); A B 1 x 2 3 a 4 5 b double click on B1 fills up to B2. MSO2016Pro, haven't checked the gazillion of options to switch behavior. > - an option should be considered to determine behavior, so that overwriting > is possible, not as default; Makes sense as an option to restore the legacy behavior (shouldn't be too difficult with the patch for bug 108209).
(In reply to Heiko Tietze from comment #22) > MSO2016Pro It's MSO365.
No further input so closing as WFM based on c21, c22.
would it be possible to add the original functionality (eg on ctrl double click)? Now it is not possible to simply copy cell contents (such as a corrected formula) into already filled cells. Thanks Or should I make a new request?
(In reply to kabilo from comment #25) > Or should I make a new request? Not sure that your issue is the same as this one. So please create a new ticket.
I don't think this was a proper bug resolution: - not WFM anyway, can be only WontFix; - "an option should be considered to determine behavior" was proposed in Comment 15 and confirmed in Comment 22, but this was closed instead; - kabilo gave a use case (corrected formula) and another proposal (use Ctrl); - new Bug 126767 seems the same to me as this one.