Description: some numbers are not recognized as numbers Steps to Reproduce: 1. Open a new calc session 2. chose field a2 3. enter 99,99 --> works fine 4. chose field a3. 5. enter 11,33 --> wrong adjustment: it is not a number! 6. chose field c2. enter a formula =A2*2 --> works fine 7. chose field c3. enter a formula =A3*2 --> result is #WERT! 8. this error occurs in many cases e.g. 31,84 Actual Results: impossible to calculate with: #WERT! Expected Results: e.g. a+b Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
Created attachment 140334 [details] reproduces the rror
cannot reproduce in front of number 11,33 there is ' and the calculation in c3 is correct no error message Version: 6.1.0.0.alpha0+ Build ID: a0d739026d21077e51bfc82ee63d04f6b4b69828 CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); Calc: group So its not a bug, if you not agree you can reopen the report as unconfirmed
Hello, this is really strange ... I changed the language settings from default-german to english-usa and tried again: everything works fine. Then I changed back to german: everything works fine, the error is gone - for all new entries! Software is a big miracle ... Thanks a lot for your assistance! Maybe it could be helpful for other users having the same problem.
p.s. when reporting the bug no ' was visible. Now it is! It was surely not my fault, I demonstrated the problem to my partner, he was able to reproduce.
Created attachment 142474 [details] movie to show the failure
Version: 6.0.4.2 (x64) this failure occurs more and more often. the only workaround in calc is "=1755/100" the same problem exists in word tables. workaround here is "=17,55"
please look at the gif file as a small movie to show the problem.
I did have a look at the gif, and yes its there ,but retested with LO6.0.4.2 and still no problem at all. Try to reset your user profile. Version: 6.0.4.2 Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); Calc: group
Hello, I did - no effect. The error seems to concern 1- and 2-digit-numbers only. e.g. 17,55 27,68 26,18 3,22 36,23 is ok 27 is ok 27,0 ist NOT ok Maybe the problem is somewhere in the german settings? When I changed to english the error was gone, then I changed back to german: it seemed to be ok - for a short time (reboot?). P.S. I can copy such a value from an elder field in the same table to a new one. That works fine …
maybe only windows because with the setting to default-german still no problem retyping 11,33 give me the correct result Version: 6.0.4.2 Build-ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf CPU-Threads: 8; BS: Linux 4.14; UI-Render: Standard; VCL: kde4; Gebietsschema: de-DE (en_US.UTF-8); Calc: group @Eike any idea???
Formatted cells to German (Germany). Could not reproduce the problem. Version: 6.2.0.0.alpha0+ (x64) Build ID: 2c85607101e2e04e870e3b87362f39f9a9148e6c CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-06-16_00:12:37 Locale: fi-FI (fi_FI); Calc: group threaded
Please test more to find a cause and pay attention to Tools-Language settings - Languages, Locale settings and Decimal separator key.
Created attachment 143559 [details] example in writer
Version 6.0.5.2 no changement in this version The same error also occurs in writer (see movie). Please look at value 5 and SUM. It is impossible to work with this fault. Version 5.4.1.2. (portable) running on the same pc works properly. writer on another laptop seems to work correctly (same Windows 10, same installation). My windows is an upgrade from Windows 7 pro. I never played with languages or other settings (separators). Language setting is: deutsch (Deutschland) deutsch (Deutschland) separator: checked currency: standard eur standard language: deutsch (Deutschland) asiatic: no complex text: no ignore system language: no
(In reply to burkhard.kasten from comment #13) > Created attachment 143559 [details] > example in writer Please, no more gifs! They are extremely user-unfriendly as browsers do not present play controls. Give steps so everyone has equal possibility to reproduce.
I can't reproduce. I have changed language (Spanish to German), both cells (a2,a3) work ok. Version: 6.0.5.1 Build ID: 0588a1cb9a40c4a6a029e1d442a2b9767d612751 CPU threads: 2; OS: Linux 4.15; UI render: default; VCL: gtk2; Locale: es-AR (es_AR.UTF-8); Calc: group Linux Ubuntu 18.04.1
I can't reproduce it in Versión: 6.1.2.1 Id. de compilación: 65905a128db06ba48db947242809d14d3f9a93fe Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; Configuración regional: es-ES (es_ES); Calc: group threaded Are you sure it's reproducible in safe mode ? Help - Restart in safe mode ?
Hello, I am using 6.1.2.1. since several weeks. The error occurs in the same way as in elder Versions. Also when started Windows 10 in safe Mode, there is no difference in behaviour. Today I help myself in reopening the file using version 5.4.1.2. portable on the same machine. Now the cell is shown correctly as '17,90 So I can fix the fault, but this is not really comfortable.
(In reply to burkhard.kasten from comment #18) > Also when started Windows 10 in safe Mode, there is no difference in > behaviour. Not Windows, but LibreOffice: Help - Restart in safe mode and then Continue in safe mode.
Sorry, soffice.exe does not start in safe mode. CTRL and double click: nothing happens. start-icon -> execute soffice.exe /safe : Start logo appears for very less than a second, then program ends immediately. Task Manager shows nothing. start-icon -> execute soffice.exe works fine. Administrator: Command prompt: same reaction C:\Program Files\LibreOffice\program>soffice /safe does not start. C:\Program Files\LibreOffice\program>soffice starts properly. I found no interesting entries in error log.
(In reply to burkhard.kasten from comment #20) > Sorry, > > soffice.exe does not start in safe mode. > > CTRL and double click: nothing happens. > > start-icon -> execute soffice.exe /safe : Start logo appears for very less > than a second, then program ends immediately. Task Manager shows nothing. > > start-icon -> execute soffice.exe works fine. > > Administrator: Command prompt: > > same reaction > > C:\Program Files\LibreOffice\program>soffice /safe does not start. > > C:\Program Files\LibreOffice\program>soffice starts properly. > > I found no interesting entries in error log. Why are you doing this, when I said you should do: Help - Restart in safe mode and then Continue in safe mode?
Sorry for misunderstanding, I did not check that easy way. calc: In safe mode calc shows the faulty cells as '17,90, the other (corrected ones) as 17,9. I can remove ' , this cell and new cells also were filled and calculated correctly. writer: Table looks unchanges - except the sum, which is now correct when in safe mode. I changed a cell, saves the file and opened it again in unsafe mode. --> sum ist wrong again.
(In reply to burkhard.kasten from comment #22) > Sorry for misunderstanding, I did not check that easy way. > > calc: > In safe mode calc shows the faulty cells as '17,90, the other (corrected > ones) as 17,9. I can remove ' , this cell and new cells also were filled and > calculated correctly. > > writer: > > Table looks unchanges - except the sum, which is now correct when in safe > mode. > > I changed a cell, saves the file and opened it again in unsafe mode. --> sum > ist wrong again. Ok, you can reset your profile to get rid of the problem: https://wiki.documentfoundation.org/UserProfile
Now the error ist reproducable: Options -> Language Settings -> Language -> Date acceptance Patterns: D.M.Y;D.M.;D.;D,M,Y,;D,M,;D, This entry allows to write dates using the digits block of the german keyboard, which bears "," instead of decimal point. The very last entry "D," causes the problem, using german as well as english language. It would be very nice to fix that.
(In reply to burkhard.kasten from comment #24) > Now the error ist reproducable: > > Options -> Language Settings -> Language -> Date acceptance Patterns: > > D.M.Y;D.M.;D.;D,M,Y,;D,M,;D, > > This entry allows to write dates using the digits block of the german > keyboard, which bears "," instead of decimal point. > > The very last entry "D," causes the problem, using german as well as english > language. > > It would be very nice to fix that. Yep, I can repro with this. The Date acceptance pattern feature is already in 4.3, but not yet in 3.5. I feel this might be a tricky issue. How to determine what the user wants to express with their typing? Setting to NEW for now.
I changed the last comma with a point and then i cannot reproduce With the comma I can also reproduce the problem
i can confirm this too. for convenience we added "D." to Date acceptance patterns. this worked by default with AOO 4.1.5, but with LO it has some side effects. steps to reproduce: - Menu Tools/Options/Language Settings/Languages -> Locale setting: "German (Germany)" -> add to Date acceptance patterns: "D." - create new spreadsheet - enable Menu "View/Value Highlighting" - cell A1, enter: 1. -> Date: 01.04.19 - cell B1, enter: -1.234,56 -> Text: -1.234,56 - Cell B2, enter: =Value(B1) -> Err:522 now remove "D." from Date acceptance patterns and - create new spreadsheet - cell A1, enter: 1. -> Text: 1. - cell B1, enter: -1.234,56 -> Value: -1234,56 - cell B2, format as Text @ and enter: -1.234,56 - cell B3, enter: =Value(B2) -> Value: -1234,56
Created attachment 151013 [details] test csv import csv import is also affected: - open attaced *.csv file - Text Import dialog options: [X] Semicolon [X] Detect special numbers -> with "D." first data row is not converted into values
Dear burkhard.kasten, 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
*Of course* defining a D. date acceptance pattern if the decimal separator is . dot as well (or D, with comma decimal separator) is asking for trouble. Geez..
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/eb0b4ab2d3b86d77ee0edb652d4486343e5b3b1f Resolves: tdf#116184 Check that there is no trailing number behind a match It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Pending review https://gerrit.libreoffice.org/c/core/+/122054 for 7-2 https://gerrit.libreoffice.org/c/core/+/122055 for 7-1
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/c2d838598add1daff8c7429432715a8dd78231f0 Resolves: tdf#116184 Check that there is no trailing number behind a match It will be available in 7.2.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/d2a78a49438134e174bb8fc83d4adb486f692ff7 Resolves: tdf#116184 Check that there is no trailing number behind a match It will be available in 7.1.7. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.