Apache OpenOffice Community Forum

Guess about the return of:
x = cint("+1")
I Think that return 1 is very sucessful.
But my macro return is 0 zero.
Apache Open Office 4.1.7 on Windows 10.

Edit: Changed subject, was cint() with error?  Make your post understandable by others  -- MrProgrammer, forum moderator

This has been fixed in LibreOffice.

https://www.libreoffice.org/discover/li ... penoffice/

It treats anything with a "+" as a string that evaluates to 0.

Strip the + or use

Helpfile (F1) says for CInt

Expression: Any numeric expression that you want to convert.

Bidouille - mine says,

CInt Function [Runtime]
Converts any string or numeric expression to an integer.

This has been fixed in LibreOffice.

Not in my LO 6.1.6, but it works in my portable LO 7.3.2

Zizi64 wrote:Not in my LO 6.1.6, but it works in my portable LO 7.3.2

LibreOffice fixed that bug [1] in 7.1
I see CInt() work correctly e.g. in version 7.1.0.2

The entry for CInt() in online Help has been expanded for version 7.3
You may compare: LibreOffice 7.2 Help and LibreOffice 7.3 Help


[1]
Bug 136801 - BASIC: CInt("+2") returns 0

In case of Apache OpenOffice — new Bugzilla issue

Issue 128518 - Basic - Converting "+1" to a number

A workaround is to make your own custom cint function, that first checks if the argument starts with a + sign, if so deletes it and then feeds the result to the original cint function. Don't expect this bug to get fixed any time soon.

Somebody's help wrote: CInt Function [Runtime]
Converts any string or numeric expression to an integer.

Yes.
But "any string" may not be recognized as "numeric", even if the user thought it was. CInt(something) generally returns the value 0 if 'something' not was accepted as numeric. Strings starting with a "+" character were not regarded numeric also by the Basic function ISNUMERIC() due to a legacy bug for a long time.
And what is accepted as a "numeric expression" in this specific context isn't explained - and isn't subject to the ODF specifications.
LibreOffice got fixed THIS bug some time ago. However, you shouldn't think the life of bugs generally is too hard in LibO.
The offhand example I just tried in Basic under LibO 7.3.3.2 returned neither an error nor a value of 0 or -67 for h, but h = 10 - and so does the less ambitious Programming in Basic you walk over cracky ice. If you need reliable results, you shouldn'tuse functions where any faint doubt exists. The help texts never are precise enough. They aren't sufficiently complete either.

BTW
In the context of formula evaluation in Calc is an error, while evaluates to -67 regarding the specifications concerning automatic type conversion.
In Basic, on the other hand, "10" + "77" makes "1077" because, based on a convention from the stone-age, Basic still uses the operator + also for concatenation if the context allows it.
Overloaded operators are a way to hell.

Write a few extra lines of code instead of trusting in doubtable automatisms.

Don't expect this bug to get fixed any time soon.

Likely. Its a trivial bug affecting the tiny subset of macro users (in turn a very small subset of users) who will ever use a "+" at the start of a string... with easy workarounds. Worth knowing about though...