And for number format, we can using it with another format too.
For example :

number_format ( QCODE , 2 , ',' , ' ' )

Documentation says to use join(arg1,arg2) for concatenation. Funny enough this function is not in the function list.

Then move to documentation.

Thanks

Problem:
join => undefined function.

Bug updated

Thomas, any idea on this?

the missing join() function is an oversight. There is an implode() function that can be used instead.

The root problem is a (perhaps misguided) effort to get + to work identically in PHP and JavaScript. For the equation "a + b", JavaScript treats + as concat() if a is of type String (even if it is numeric). So, ExpressionManager (one of the RDP_xxx() functions) tries to emulate that behavior in PHP.

In retrospect, this may cause more problems than not, so I'd be happy to have + always mean "add" and force users to use join(), or implode() to do concatenation.

So, recommendations are:
(1) Add join() function to EM (or change documentation to have them use implode())
(2) Make "+" always mean add (and never concatenate), and let it throw a NaN exception as needed.

/Tom

Think implode are made for array, not to concatenate string.

1st: join(2 var) , see after for 3.... and more

The EM implode() function does work for contatenating strings (e.g. the function takes an unlimited number of arguments), even if the original PHP implode() function was meant for arrays.

Think some user use + only for addition, sometimes with "10"+"10", then you break their survey.

Maybe:
If $bNumerci : +
else concatenate

And adding join

em_core_helper:
case '+':
if ($bBothNumeric) {
$result = array(($arg1[0] + $arg2[0]),$token[1],'NUMBER');
}
else{
$result = array($arg1[0] . $arg2[0],$token[1],'STRING');
}

1.92 and 2.0 both already have this code for RDP_EvaluateBinary()

case '+':
if ($bBothNumeric) {
$result = array(($arg1[0] + $arg2[0]),$token[1],'NUMBER');
}
else if ($bBothString) {
$result = array($arg1[0] . $arg2[0],$token[1],'STRING');
} else {
$result = array(NAN,$token[1],'NUMBER');
}
break;

So the problem is likely in em_javascript.js or GetJavaScriptEquivalentOfExpression()

I propose to remove the if ($bBothString) test.

Then if both can be numeric Adding else concatenate.
Don't look at javascript now.

From what I can tell from the forums and from other Limesurvey users I have been working with, "+" is used a lot to concatenate strings/messages and you never know how many users make use of it without us ever having noticed them.

Thus, I really wish to not change the way that function is currently used. It might break dozens or hundreds of running surveys.
Instead, better find a code-wise workaround by using some try-catch statements or the like to handle the special cases we are talking about while keeping the current functionality available for our existing users.

Of course, updating the manual and giving some examples when which functions should best be used, does no harm :-)

Mazi:
For starting: it's this OK:

{"10"+"10"} : 20
{"$"+"10"} : "$10"
{"A"+"B"} : "AB"

Actually we have
{"10"+"10"} : 20
{"$"+"10"} : NAN
{"A"+"B"} : "AB"

(Adding join function in php and js after)

The second file show behaviour with same group:
No NAN: but is both can be numeric : sum
If not concatenate.

Fix committed to master branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=11547

Fix committed to master branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=11549

New version 2.00 build 120206 released.

Fix committed to 2.1 branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=11608

Fix committed to 2.1 branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=11609