Description: Calc can't divide on a Windows 8.1 computer if a number is divided by a non-integer. Works correctly with LibreOffice running on Linux Mint 19.2 Cinnamon 64-bit Steps to Reproduce: 1. Open LibreOffice Calc on a Windows 8.1 with Bing 64-bit computer 2. In cell A1 type: 48.04166667 3. In cell B1 type: =A1/1.1 Actual Results: Cell B1 shows: #NAME? Expected Results: Cell B1 should shows: 43.6742424272727 Reproducible: Always User Profile Reset: No Additional Info: Version: 6.3.0.3 (x64) Build ID: c75130c129d9c5e43b76e4f26881b3db8bdb5c91 CPU threads: 2; OS: Windows 6.3; UI render: default; VCL: win; Locale: en-AU (en_AU); UI-Language: en-GB Calc: threaded Windows 8.1 with Bing 64-bit operating system, x64-based processor
Created attachment 153223 [details] Test file Cell B1 incorrectly shows #NAME? on Windows 8.1 Cell B1 correctly shows the value on Linux Mint 19.2 Thank you
Cannot repro with Version: 6.3.0.4 (x64) Build ID: 057fc023c990d676a43019934386b85b21a9ee99 CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: CL
And also *cannot* repro with the same but Calc: threaded
Created attachment 153225 [details] Screenshot with LibreOffice 6.3.0.4 (x64) Maybe there is more information in the screenshot that can help? When LO was installed, only the English (GB) was selected. English (US) etc was unselected. Hope this helps in reproducing this bug. Thank you
(In reply to Óvári from comment #4) When installing: 1. `Optional Components` --> `Dictionaries` --> all unselected except `English` and `Hungarian` 2. `Additional user interface languages` were all unselected except `English (United Kingdom)` Thank you
no repro with: Version: 6.3.0.4 (x64) Build ID: 057fc023c990d676a43019934386b85b21a9ee99 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: xml representation of attached file is: <table:table-row table:style-name="ro1"> <table:table-cell office:value-type="float" office:value="48.0416666666667" calcext:value-type="float"> text:p>48.0416666666667</text:p> </table:table-cell> <table:table-cell table:formula="of:=[.A1]/1.1" office:value-type="string" office:string-value="" calcext:value-type="error"> <text:p>#NAME?</text:p> </table:table-cell> </table:table-row> maybe a problem with "Decimal separator key" ? -> Menu Tools/Options.../Language Settings/Languages/Decimal separator key
(In reply to Oliver Brinzing from comment #6) > maybe a problem with "Decimal separator key" ? ... which shouldn't be a problem; en-AU and en-GB use decimal dot; and - no problem with ru-RU, which uses decimal comma. > -> Menu Tools/Options.../Language Settings/Languages/Decimal separator key ... which is a different unrelated setting, telling what to do when a specific key is pressed on keyboard, not about which separator to use (see [1]). [1] https://help.libreoffice.org/latest/en-US/text/shared/optionen/01140000.html
CTRL-SHIFT+F9 helps?
the only way i found to reproduce a file like the attached one is (with: Locale: de-DE (de_DE)): 1. In cell A1 type: 48,04166667 2. In cell B1 type: =A1/1.1 3. B1 shows #NAME?, cause decimal separator should be "," 4. save spreadsheet but reloading the file will correct the error.
(In reply to raal from comment #8) > CTRL-SHIFT+F9 helps? No
(In reply to Oliver Brinzing from comment #9) > the only way i found to reproduce a file like the attached one is > (with: Locale: de-DE (de_DE)): > > 1. In cell A1 type: 48,04166667 > 2. In cell B1 type: =A1/1.1 > 3. B1 shows #NAME?, cause decimal separator should be "," > 4. save spreadsheet > > but reloading the file will correct the error. The decimal separator is in Australia is "." not ",". Thank you for your suggestion. Tested your suggestion of saving, closing and re-opening the spreadsheet and this corrects the error; however, shouldn't this error not be present to begin with?
(In reply to Oliver Brinzing from comment #6) > maybe a problem with "Decimal separator key" ? > -> Menu Tools/Options.../Language Settings/Languages/Decimal separator key No error here, as the decimal separator key is shown correctly
I see two problems here: 1. Some situation where decimal dot is not treated as such on a system where it seemingly should. The questions: What is your Windows decimal separator setting (although that likely should not affect this)? Why "User Profile Reset: No"? ;-) 2. Having such an error made by a user on a locale with decimal comma (like ru-RU), the legitimate error shown in the document disappears after save-and-reload (so the input with dot, which rightfully isn't recognized as a valid separator, is written into the file (where only dot is expected as separator), and then everything is fine) - but I'd expect that error stays error after reload.
(In reply to Mike Kaganski from comment #13) > 1. Some situation where decimal dot is not treated as such on a system where > it seemingly should. The questions: What is your Windows decimal separator > setting (although that likely should not affect this)? Why "User Profile > Reset: No"? ;-) Óvári: can you reply to this?
(In reply to Buovjaga from comment #14) > Óvári: can you reply to this? No longer have Windows as we have fully transitioned to GNU/Linux. Thank you