Created attachment 122772 [details] Demonstration Writer document with macro The cInt function treats string "1,234" as being 1. This is true on 3 different operating systems on 2 different PCs, all of which are defined as being in the EN GB locale using '.' as the decimal point in the language settings (I have double-checked this). I have tested this on: ubuntu 14.04 64 bit, Version: 5.1.1.1 Build ID: 1:5.1.1~rc1-0ubuntu1~trusty1 CPU Threads: 8; OS Version: Linux 4.2; UI Render: default; Locale: en-GB (en_GB.UTF-8) (from ubuntu pre-release PPA) Windows 7 (on same PC) Version 5.0.4.2 (from Libreoffice website) xubuntu 15.04 (a 64 bit laptop), Version 5.0.5.2 Build ID: 1.5.0.5-rc2-0ubuntu2 Locale en:GB (en GB.UTF-8) (from ubuntu release PPA) I don't how far back this issue goes. It's easy to work-around, just use format to remove the ','s, but could fool people for a long time if in the middle of a complex algorithm. I attach a Writer document demonstrating this. Press the button to see what "1,234" turns into. The macro is in 'Module1', 'Main', and just says: Sub Main Dim sText as String Dim iIntText as Integer sText = "1,234" iIntText = cInt (sText) MsgBox "1,234 becomes" & iIntText End Sub I originally found this using Basic in Base. I thought I'd demonstrate it in Writer just to show it was nothing to do with Base. Or am I being really stupid?
Repro. Win 7 Pro 64-bit, Version: 5.1.0.3 (x64) Build ID: 5e3e00a007d9b3b6efb6797a8b8e57b51ab1f737 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; Locale: fi-FI (fi_FI) LibreOffice 3.5.0rc3 Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735
I have tried to verify that my understanding of the correct behaviour of cInt is correct. I've not found any absolutely definitive source, although several websites recommend using it as opposed to 'Val' because it tolerates regional variations better.
(In reply to tim from comment #2) > I have tried to verify that my understanding of the correct behaviour of > cInt is correct. I've not found any absolutely definitive source, although > several websites recommend using it as opposed to 'Val' because it tolerates > regional variations better. I just found this: http://www.csidata.com/custserv/onlinehelp/vbsdocs/vbs79.htm Which claims to be from Microsoft for Visual Basic. It says: "Use the CInt function to provide internationally aware conversions from any other data type to an Integer subtype. For example, different decimal separators are properly recognized depending on the locale setting of your system, as are different thousand separators."
** 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.5 or 5.3.0 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-20170306
The bug is still present on 64 bit ubuntu 16.10, librefoffice: Version: 5.3.1.1 Build ID: 1:5.3.1~rc1-0ubuntu1~yakkety0 CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: x11; Layout Engine: new; Locale: en-GB (en_GB.UTF-8); Calc: group All Language Settings are set to GB.
** 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
Retested under Version: 6.0.2.1 Build ID: 1:6.0.2~rc1-0ubuntu0.17.10.1~lo1 CPU threads: 8; OS: Linux 4.13; UI render: GL; VCL: gtk2; Locale: en-GB (en_GB.UTF-8); Calc: group The behaviour is unchanged. 1,234 is still transformed to be 1 (rather than 1234), regardless of the fact that I am in the UK, with UK settings.
The bug is still present on: Version: 6.1.5.2 Build ID: 1:6.1.5~rc2-0ubuntu0.18.10.1~lo3 CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: x11; Locale: en-GB (en_GB.UTF-8); Calc: group threaded
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4fdc90c51e6a1bbb83c1f1826ad5b90dc1ff0ad6 tdf#97983 - Added localization for numeric types It will be available in 6.5.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.
Andreas: thanks for working on this. However, I still get "1,234 becomes1" when I press the button in the example document. Arch Linux 64-bit Version: 6.5.0.0.alpha0+ Build ID: 7e403195e574be5174815a51cf5c42f06f76a87a CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: kf5; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 1 December 2019
Yes I see, I missed some of the functions without a standard parameter, I will send a follow up patch tomorrow. Thank you for the test!
Hm, just a stupid question: with your locale (Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US) this example should return 1 and for an an English locale the example will return 1234. So I think the patch is correct.
(In reply to Andreas Heinisch from comment #13) > Hm, just a stupid question: with your locale (Locale: fi-FI (fi_FI.UTF-8); > UI-Language: en-US) this example should return 1 and for an an English > locale the example will return 1234. So I think the patch is correct. Argh, sorry, you are right. I tested by running with LC_ALL=C and indeed I get "1,234 becomes1234" with en-US locale.
Created attachment 156252 [details] test cInt Please add an entry to the release notes, cause this change can affect existing basic code.
Thank you for the hint! Done: https://wiki.documentfoundation.org/ReleaseNotes/6.5#Base
