Created attachment 117758 [details] A spreadsheet which illustrates the problem The SUM button is apparently designed to sum the entire column if no range is selected. It also apparently has traps in this case to detect the presence of another sum function higher up the column. If the user manually selects the range they want to sum, this backfires badly!!! It seems to be impossible to get the sum button to correctly sum column E of the attached example. No matter what range of cells you select, it always gives a result of 55, ie the contents of E7. Even if you haven't got a selection, it should at least sum E6 and E7. And (from the point of reproducibility) it gets worse. In my previous test spreadsheet - which I didn't bother to save :-( - it at least correctly summed the entire column (looked at mathematically, at least, if not logically). I can't get this spreadsheet even to do that! And yet, if you alter the mix of sums and literals in the column, it seems to work okay. In my first attempt to create this spreadsheet, I had a different mix of sums and literals, and it seemed to work fine. The problem seems to be where you sum a column to get a subtotal, then add further values below the subtotal and attempt to sum it to get a full total. The sum button refuses to include the subtotal in the formula, whatever you do. Cheers, Wol
Hello Anthony, Thank you for reporting the bug. Can you see if bug 62279 and bug 71339 are similar to your problem so that I can mark your report as a duplicate of it? (Later bugs are generally marked as duplicates of earlier bugs). Thank you.
Please try with 5.0, it's a little hard to follow your report (lots of text that is not clearly enumerated makes reading a bug report hard). What I did: Ubuntu 15.04 x64 LibreOffice 5.0.0.5 1. Opened the file; 2. Observed column E; Observed: E7 = 55, E6 = 200 (sum of E1:E5) This seems to conflict with your report. Setting to NEEDINFO - please try with 5.0, and then please provide a clearer set of steps to reproduce (just the steps, no need for *anything* else). After you've done this please set the bug to UNCONFIRMED. Thanks
raal: Yes, those bugs seem similar. 71339 in particular - the autosum button is not acknowledging the fact that the user has told it what it is supposed to sum. 62279 is bemoaning a slightly different problem - when autosum guesses, the guess is stupid. So I would say that 71339 and 93257 are the same - autosum ignores a pre-existing selection, but that 62279 is different, complaining that autosum guesses wrong when NOT passed a pre-existing selection. Joel: Click on E6. Shift-click on E8. You now have three cells selected, yes? Now click on autosum. E8 will be filled by the number 55. 200+55=55???? In fact, for your first click, pick on pretty much ANY cell in column E, and you will get 55 in E8. That basically is the bug - you cannot pass a selection IN to autosum, you have to autosum first and select after, which is completely non-intuitive, and contrary to every other spreadsheet I know (admittedly a very small set). I'll build 5, and see if I can reproduce it there, but Eike said it was a design decision. A design decision to ignore what the user asked for???? and give them something else????
(In reply to Anthony Youngman from comment #3) > > So I would say that 71339 and 93257 are the same - autosum ignores a > pre-existing selection, but that 62279 is different, complaining that > autosum guesses wrong when NOT passed a pre-existing selection. > Thank you, closing bug. *** This bug has been marked as a duplicate of bug 71339 ***