Probably because Translate() returns a string and the "+" is fooled. This code: /**/ Test="1" Test2=Translate(Test,"01","10") say datatype(Test) say datatype(Tes2)
will output: NUM CHAR
And if you add Trunc() to your original code, like: Test2=Trunc(Translate(Test,"01","10")) you have the expected behaviour.
Look at the two examples in the very first post, and notice that the only difference is adding SomeUnusedVar=Test+26 (or an IF statement using the Test variable).
At the bottom of the first post I also noted that I checked with DataType() already to verify that the Test2 variable is NUM.
The reason your example outputs CHAR is because of a typo. The variable "Tes2" does not exist. Test2 is NUM.
If I use Trunc, I get 1 and 1 as the output if I add an IF statement that shouldn't do anything.
/**/ Test=1 IF Test=1 THEN NOP /* Or any DO ... END statement */ Test2=Trunc(Translate(Test,"01","10")) SAY Test2 SAY 0+Test2 Exit
Output:
1 1
The output from Trunc is 1 when it should be 0 (the Translate function swaps 1 to 0). If I remove IF Test=1 THEN NOP, a line which shouldn't do anything, then I get the expected output of 0 and 0.
Edit: Corrections.
Edited by MickJT on 2017/4/25 19:29:16 Edited by MickJT on 2017/4/25 19:30:17 Edited by MickJT on 2017/4/25 21:07:21
Yeah, it's strange. I wanted to use SubStr() and if a particular user setting was 0, it would need to read one more byte. My way which I thought was clever was to just use Translate() to swap 0 and 1 around. For example: Test=SubStr(Output,Length+Translate(Setting,"01","10"))
That works unless the Setting variable has been checked with IF in the past.
I could rename the setting to do its opposite and then avoid using Translate(), but it wouldn't be as intuitive. Easy enough to work around though.
Thanks for testing it with OS3.9. I hadn't tried that.