Created attachment 108359 [details] Example file. Same data over several rows. Showing result of each additional click. Problem description: This has been a long time issue, probably carried over from OO. Whenever I'm working with numbers and trying to get some averages in general or per week, month, etc LO will randomly show anywhere from 3 to 5 even 7 decimals (based on space?). Then when I click the remove decimal button, the cell goes ### (number doesn't fit) because it kicked the decimals up to ten; and only then takes one decimal away at a time with each click. In many cases I've seen now that going from 3 decimals to 2 requires 8 clicks. From 3 to zero requires 10 clicks. Steps to reproduce: 1. Brand New Spread Sheet 2. A1= nnnnnn.nn 3. B1= nnn 4. C1 = A1/B1 5. Result is nnnn.nnnnnn 6. Click delete decimal space button ( example a1: 123456.78 b1:123 ) Current behavior: cell goes ###, adding more decimal spaces, up to 10, then deletes one with each additional click Expected behavior: Remove one decimal right away, do not add extra decimals first PS: I have seen this behavior both in pc and mac versions of calc OO and LO. Additional note: I believe the delete decimal function to work properly when there's only one or two, but acting up when there are three or more. Anytime it defaults to 3,4,5,6 etc. it takes several additional clicks to remove one or two, because it jumps to 10 first. (through the LO feedback page I can't seem to submit a file, in safari, says data not loaded try again in a few secs, will try file separately, or firefox, maybe? no doesn't work in firefox either? ... trying bugs freedesktop)
Reproducible with LO 4.3.2.2 (Win 8.1), after step 6 I get also "###" As far as I know LO is showing and calculating (?) 10 decimal places if there is enough space or less if there is less space. Under TOOLS -> OPTIONS -> LIBREOFFICE CALC -> CALCULATE it is possible to limit decimal places. Of the function PI() LO calculates/shows at maximum 14 decimal places.
Thanks, Andy. Just earlier today learned about the decimal limiter preference option, but I'm hesitant to use it. Guess I could set it to four decimals (rather than two) as 3-4 that is the max I typically use. Still think though that the exhibited behavior of going from 4,5,6 decimals shown to 10 and then down one at a time, is not the proper or expected behavior.
I would agree, the reported behavior is buggy.
** 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.0.5 or 5.1.2 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: 2016-04-16
** 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.2.7 or 5.3.3 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-20170522
Problem still persists, but in testing I should clarify that it is in part visual. Technically works fine ... just not as visually expected. Just downloaded the latest FRESH version on Windows: 5.3.4. Created new spreadsheet in CALC. I picked two random numbers: Cell one: 2344 Cell two: 13 Cell three: 2344/13= 180.307692 When I click decrease indent, it goes ### Then one has to keep clicking decrease indent, until it finally shows 180.307692 again, and then after that it takes one decimal off at a time. My expected behavior is to take an indent away based on what I see on screen.
** 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 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 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear icerabbit, 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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
*** Bug 92985 has been marked as a duplicate of this bug. ***
The reason of this behavior is that "General" format has no fixed decimal places: it is adapted to column width and precision (scientific format may be preferred for large or small values). As there is no specified format (number places is undefined), "Add/Delete Decimal Place" fixes decimal places to the maximum given by precision. The easiest workaround I found is to first apply "Format as Number" with one of these ways: - button "Format as Number" in Format toolbar (just left of "Add/Delete Decimal Place" - keyboard shortcut Shift+Ctrl+1 - sidebar "Number format" section: modify "Leading zeroes" or change category to Number
I understand that applying cell formatting to a specified type and notation will change this behavior. LO's behavior could be enhanced. As, for end users and people new to the program, this is not desirable; when this issue is not present in competing commercial programs. Other products understand logically, that if a cell or table space shows 4 decimals in a default cell, reducing means show 3 decimals, and again gets it to show 2 cells. This less than ideal behavior is still present in LO 7.0.3.1 I have a cell: =(F35*E35)+(D35*$D$21/60) With a calculated value of 8.333333333333333333333... LO Shows this as 8.3333 Clicking Reduce Decimals makes it #### Clicking it nine more times I am back at 8.3333 Clicking it two more times I am at 8.33 Something other programs do by default in two clicks, regardless of formatting.
Yes, this behaviour is annoying and undesired. In addition, for those who start with libreoffice it is disconcerting. To resolve the situation, they have to learn some of the techniques listed above. Or simply pressing "reduce decimals" too many times. It is discouraging. It should revert to the situation in previous versions.
*** Bug 157651 has been marked as a duplicate of this bug. ***
*** Bug 157514 has been marked as a duplicate of this bug. ***
Created attachment 193059 [details] reduceDecimalPlaces.ods: several situations trying to reduce decimal place The function handling this is ScViewFunc::ChangeNumFmtDecimals(bool bIncrement) It isn't as bad as it originally sounded, IMHO. Most situations handle it correctly. When a range of cells is chosen, only the "current" cell is evaluated - that seems logical and simplifies things. The problem happens in the "General Number" case, when there is not enough space to display the whole number. In that case, the program is allowed to "round" the number based on the column width instead of showing ###. However, the "real" number is more decimal places than can be shown. By decreasing the decimal point, we now force X number of decimal places, which in the "auto-rounded" cases likely means it won't fit any more. In other words, you will only see this problem on cells where more decimal places will be shown if you increase the width of the column. So this depends on font size, zoom level, etc.
Getting what is actually displayed in the cell is not easy. It is NOT one of these: rDoc.GetString(nCol, nRow, nTab) ScCellFormat::GetInputString(aCell, nOldFormat, *rDoc.GetFormatTable(), rDoc) ScCellFormat::GetOutputString(rDoc, aPos, aCell) In fact, I think the shortened string just ends up being drawn to a screen position, and never ends up as an actual string stored anywhere. mpDev->DrawText(aDrawTextPos, aShort, 0, -1, nullptr, nullptr, ... in ScOutputData::LayoutStrings where aDrawTextPos is an X,Y coordinate, and aShort is ScDrawStringsVars::GetString where (m_)aString was set in ScDrawStringsVars::SetTextToWidthOrHash That pretty much makes this bug impossible to solve without doing massive edge-casing. It certainly doesn't seem to be a logical flaw...
(In reply to Justin L from comment #16) > That pretty much makes this bug impossible to solve without doing massive > edge-casing. It certainly doesn't seem to be a logical flaw... I did some testing as well and I can confirm everything you said. One idea I had is the following: Currently, when bWasStandard is true, we test the output string to figure out the value of nPrecision. However, the output string can be much larger than what would fit on the screen. Instead we should define nPrecision by the amount of text that would fit in the cell. This probably could be done by dividing the cell width by the width of a single character. Then we could figure out how many decimal numbers are probably being displayed on the screen to determine nPrecision. Since this would only be needed for the current cell (not the entire range), than it shouldn't be too costly.
(In reply to Rafael Lima from comment #17) > Instead we should define nPrecision by the amount of text that would fit in > the cell. This probably could be done by dividing the cell width by the > width of a single character. Then we could figure out how many decimal > numbers are probably being displayed on the screen to determine nPrecision. You need also to check if General format chose a scientific notation to better fit in column width.