Forums Bug Reports $iif causes /reseterror

when mIRC 6.2 jumps to the :error goto point, using an $iif causes a /reseterror as seen with this code:

ON 1500:TEXT:.*:*: {
$eval($2-,2)
:error
echo -a $error
msg $iif(#,#,$nick) $error ERROR FAILED
echo -a $error ALSO FAILED
}

the first error will echo just fine but the second error will not evaluate unless evaluation brackets are used and even then any subsequent $error will not contain anything.

Well $error wont catch "<command> Unknown command" and evaluating $2- as a command is very dangerous even if it is for a ulevel of 1500.
However you seem to be right

as suppose to


I have no clue why it would do such a thing because no error in the :error section seems to retrigger the :error handling.

You could save $error into a %error variable prior to using $error. However this wont stop from /reseterror to be triggered and therefor not propagate backwards to any calling aliases which might be the behaviour you want.

I'd only add that this isn't particular to $iif(), any alias called after mirc jumps to :error causes /reseterror:

/alias test noop

//return $or( | :error | echo -a 1: $error | test | echo -a 2: $error

The reason $iif() does this too is that it's one of those "internal" aliases: each time you call it,

/!if (%s) { /!return 1 } | /!else { /!return 0 }

is executed behind the scenes.

will output
this: * /echo: insufficient parameters (line 9, script9.mrc) cool FAILED
yay
this: testerror FAILED

It seems odd behaviour though to me since cool reset the error testerror shouldn't trigger an error since /reseterror indicates don't propegate to the calling alias's error .


Wheter these 2 are related or not i don't know

This one is normal, you just forgot a /return after "echo -a yay"

Thanks this has been fixed for the next version.