Post: #12

I solved the problem. I thought that a list of arguments, separated by commas, was auto-typized: if argument 1 is a string, <ARGV[0]> is treated as a string, if argument 2 is a number, <ARGV[1]> is treated as a number. So, if i passed as the second argument "12" and in the function i do SAY <ARGV[1]> it would show 0c instead of 12, because numbers are automatically parsed in hexadecimal.
Though, doing SAY <ARGV[1]> shows "12" and not "0c", so in this case argument is treated as a string and not as a number, i was wrong.
The problem lies in the LOCAL._TEXT=<ARGV[4]> in my function (5th argument is the text). If i assign the value of <ARGV[4]> to a local (tag, var, whatever), sphere automatically recognizes the type of the argument, and internally set the local to be a numeric variable, since i am passing "12". So, as numerical variables are parsed in hex, doing SAY <LOCAL._TEXT> will show "0c", both in the case i passed "12" (so it was like LOCAL._TEXT=12) and in the case i passed "0c" (like LOCAL._TEXT=0c).
On the contrary, SAY <ARGV[4]> shows "12" if the argument is "12" and "0c" if the argument is "0c". This because internally <ARGV[4]> is a string, so it have not been parsed in hex or in decimal.

To sum up, i was misled by the fact that:
.test 12 shows first 12, second 0c. The explaination is the one above.
It's like doing:
I don't know if a number or a text will be passed to the function, so i cannot do SAY <EVAL <ARGN>> or SAY <HVAL <ARGN>>.

In my code i did:
And i got that problem, which i solved doing this: