Description: The problem occurs when the cint (string to integer) function is used in a macro on strings in which the system language (e.g. German) expects the decimal place after a comma, but in the cell we have an (English) number with a point. A system-compatible number (e.g. 530,3) is interpreted correctly (cint then returns 530), while a point (like a thousand point inserted for readability) is simply ignored. But the result for 530.3 is 5303! There can be an ambiguity in cases with three digits after the point. But in the example above, I would expect to either accept the point like a comma, or at least just ignore the point and the digit after it. Steps to Reproduce: 1. In a system, where the comma is used in front of the decimal place, write an English number with a single decimal digit behind the point into a cell. 2. Call a macro on this cell, reading its string and calling the cint function to get the corresponding integer for this string. 3.Check the result Actual Results: The result using 530.3 is 5303. Expected Results: The expected result would be 530 Reproducible: Always User Profile Reset: No Additional Info: None
Created attachment 176274 [details] The spreadsheet contains a macro function calling cint on the cell two rows left
I can't repro *exactly* using Russian set as program locale: both > MsgBox CInt("123.4") and > MsgBox CInt("123,4") result in "123" shown in the dialog. However, this is still a bug. (In reply to Fritz R. Paul from comment #0) > But in the example above, I would expect to either accept the point like a > comma, or at least just ignore the point and the digit after it. The expectation in the description is wrong: what should happen is error, where the input string can't be converted to a number. For comparison, in VBA one of the two calls above gives Run-time error "13": Type mismatch.
I can confirm a (mysterious) change in behaviour of the cint command in the 7er versions. with English local language setting: In all previous versions (and OpenOffice) something like cint("1,a") gave 1 cint("1,e") gave 1 cint("1,e2") gave 1 In LO7 all above give 0 In German local setting the "e" is suddenly treated as exponent: In all previous versions (and OpenOffice) something like cint("1,a") gave 1 cint("1,e") gave 1 cint("1,e1") gave 1 cint("1,e2") gave 1 In LO7: cint("1,a") still gives 1 cint("1,e") gives 0 cint("1,e1") gives 10 cint("1,e2") gives 100 I don't know what's going on but report it here. Tested on Windows 10 and LinuxMint17 and 21.
Regression, based on comment 3.
(In reply to BogdanB from comment #4) > Regression, based on comment 3. No, that is not a "regression", the comment 3 is irrelevant for the problem at all. It talks about something different, and what's more - about the *correct* fixed behavior, where the function now correctly converts the scientific notation.
(In reply to Mike Kaganski from comment #2) > However, this is still a bug. Heh, no. This is not a bug. CInt ignores thousand separator in any place inside the number, also in Excel. My previous test failed, because in my locale, neither , nor . are thousand separators (a space is); now I tested using different locales and actual separators.