toInteger() parameters

Non-numeric characters will be removed and any decimals will be rounded down.

I solved the case by cleanwith(). But the issue still exists. toInteger() function allows incorrect input which is terrible.

Yea, Appian implements a toInteger() in a very similar way to JavaScript, where all non-integer characters are stripped, and the remaining are used to create the integer. www.w3schools.com/.../jsref_parseint.asp

It's important to note here, that Appian's toInteger() does not convert strings that representation of numbers in a different base (such as hexadecimal). "0x10" will convert to 10 (010, drop the leading 0), and not 16 (which is decimal representation of hexadecimal number 10).

As you must ensure the input from your users is indeed a integer number, I agree, you cannot rely on toInteger, or an integerField. I would recommend using a textField to gather the end user input, and placing a validation to ensure they input an integer. A very quick thought would be to compare the length of the input string, with the length of the toString(toInteger( input string) ). If they are the same, you know the user entered a valid integer. See below code snippet as a quick example for this comparison.

load(
local!data: "m2",
len(
toInteger(
local!data
)
) = len(
tostring(
local!data
)
)
)

Since toInteger strips the 'm' from our data, the lengths will not be the same. Representing that local!data was not composed of only integers. This will return false if the data is a decimal and not an integer.  (Wanted to expand a bit on my previous comment)

Yea, Appian implements a toInteger() in a very similar way to JavaScript, where all non-integer characters are stripped, and the remaining are used to create the integer. www.w3schools.com/.../jsref_parseint.asp

It's important to note here, that Appian's toInteger() does not convert strings that representation of numbers in a different base (such as hexadecimal). "0x10" will convert to 10 (010, drop the leading 0), and not 16 (which is decimal representation of hexadecimal number 10).

As you must ensure the input from your users is indeed a integer number, I agree, you cannot rely on toInteger, or an integerField. I would recommend using a textField to gather the end user input, and placing a validation to ensure they input an integer. A very quick thought would be to compare the length of the input string, with the length of the toString(toInteger( input string) ). If they are the same, you know the user entered a valid integer. See below code snippet as a quick example for this comparison.

load(
local!data: "m2",
len(
toInteger(
local!data
)
) = len(
tostring(
local!data
)
)
)

Since toInteger strips the 'm' from our data, the lengths will not be the same. Representing that local!data was not composed of only integers. This will return false if the data is a decimal and not an integer.  (Wanted to expand a bit on my previous comment)