Here's an example, made in clear mirc:


When i perform /test, appears an error:


When i perform /test2:


When i perform /test3 și /test4 all works!

So, is a bug with $iif() that not evaluate the commands in it? I used mirc version 7.64 till this new version 7.71 and $iif(%test == $null,%test = test) works fine!

After some quick testing it seems this issue started in v7.67.

I'm guessing this caused it:

Ohh shit.. i undertsand.. but take attention that set,inc etc. works fine.. here is the problem in $iif() not in set.. because in if () works fine and $iif() results bugs.. see my examples!

I've only posted to help figure out when the issue started.

Best to wait for Khaled to respond.

This is going to be tricky...

One needs to understand that what's going on here should not be viewed as a bug, you're inside an identifier, $iif, it is normal behavior for $iif to evaluate the 'iftrue' parameter of $iif.

Of course, this has nothing to do with $iif, all identifiers will behave the same way (more or less).

I'm afraid mIRC is now getting it correctly, you can use $iif(%test == $null,set % $+ test test) if you want to set the variable inside $iif.

Note that $iif is a super slow identifier anyway, as it's calling /if internally, the proper, and therefore much faster way to do a condition and set a variable accordingly is what you did in the test3 and test4 alias.

There still might be some concern though, because $iif(1,% $+ test = 1) executed as a command sends %TEST to the server, it does not set, whereas $iif(1,set % $+ test 1) will set correctly, probably related is that $(%a = 1) used to return "set %a 1", and no longer does (return "= 1"), which should never be an issue in itself.

The change in v7.67 was made due to how variables were being evaluated/not evaluated by /set/inc/dec/etc. in different contexts. See here for the original discussion.

The issue with $iif() was discussed here some time ago.

The problem is that the items in $iif() are parameters, so they need to be evaluated, in the same way as all identifiers have their parameters evaluated.

The issue that i must replace tons of lines where i have $iif(%var == $null,%var = 1) to if (%var == $null) %var = 1 or to $iif(%var == $null,set $chr(37) $+ var 1) .. i located that if i unset %var before $iif() also works.. but is the same to make changes. Although, I thought is a way to change this issue to avoid the break of the existing scripts.

I assume you read the link, and the link in the link. This wouldn't be the 1st time that scripts using wrong syntax that works ended up having a broken script when that was fixed.

I had a script I'd made in the version 6.x era where I had unknowingly had a line in a popups label having an extra closing parenthesis. Everything was fine through several versions, until one day I was flooded with irritated users who had a flood of error messages in their status window, because they'd upgraded to a newer version that was no longer forgiving of the extra parenthesis. Luckily in that case it was simple to fix.

If this were to change to support the old broken syntax, then either people who've been using the new+correct syntax will now be broken, or else mIRC would be forced to support all of:

$iif(%test2 == $null,set -s % $+ test2 test2)
$iif(%test2 == $null,set -s %test2 test2)
$iif(%test2 == $null,set % $+ test2 test2)
$iif(%test2 == $null,set %test2 test2)

And also doing the same for /inc /dec /sockread /sockread

And just an observation about the

%test = test

..syntax in your example. I know it's valid, but I prefer not to use it, because it's more ambiguous as to whether the intent is to be setting a %global or %local variable. I most commonly see this form used by new scriptors who don't realize that doing this is creating global variables that they don't realize are being set, where they can either cause problems for another script that erroneously didn't initialize their variables, or else this stuff ends up bloating up the vars.ini with stuff that goes global but never gets cleaned up.