Forums Bug Reports /queryrn

/queryrn doesn't work correctly if the old nick is similar to the new nick for example:

/queryrn cow Cow
It replys with * /queryrn: invalid window

i wonder why this wasn't reported before

That wouldn't work because the two names are the same. Window names for queries and channels are not case sensitive, so cow and Cow are identical, not similar.

That makes it even odder. Why would it be an "invalid window"?

I see your point about the message. The only time I got that response in my testing was when the two names were identical (based upon my earlier observations). When I used the command with two different names (example: Bob and Pete) it worked properly.

My best guess is that it's simply a badly worded error message.

It should be possible to reformat the capitalisation, though. Simple workaround:

omg, do u know what using $$n does?

Do you know what :error does? You keep using it places where it does nothing.

Also you're missing a parenthesis in the first if condition and there's no point checking $len($1) anyway.

yeah i do know what it does, for some reason my edit didnt come through, i made my changes to the script and hit submit by error and went back straight away and edited it but it didnt come through

pre edit i forgot to write the rest of the line ":error | reseterror" got side tracked remebering it shouldnt run on $identifier use,

re: the error trap while this doesnt completely make a customized command exactly the same as an orginal one, i feel its better than the chance some other part of the code might error, out side of the original command. This was also what disturbed me about his use of $$n.

As for the missing bracket its actually ment to be at the end of the 2nd if, i corrected that in the edit as well

and as for the $len, your wrong $len($1) becomes true on $1 being $false or simple numeric representaion of 0 such as 0, 000.0, 0000.000, etc, I often check for these possabilities, be it needed or not in the particular instance.

Err, yes, I believe I do. You seem to be implying that it does more than it says in the helpfile:



Or were you just commenting on the fact that I overused it a bit? (That's cos I cba to remove the two that I'd already used)

$$ stops not only the current routine but the entire call chain (kind of like an "if ($1 == $null) halt"). I doubt it matters much in this case though.

if ($len($1) && ($1 != $2)) { queryrn $1- }
why check for the length of $1 to begin with in this case ? If $len($1) (or $len($2) or both for that matter ) returns 0 it can never be the same as $2 anyway ?

//tokenize 32 0 0 | if ($1 != $2) echo -a $1 *No trigger
//tokenize 32 0 1 | if ($1 != $2) echo -a $1 *Trigger
//tokenize 32 0 | if ($1 != $2) echo -a $1 *No trigger
//tokenize 32 0 | if ($1 != $2) echo -a $1 *No trigger
//tokenize 32 | if ($1 != $2) echo -a $1 *No trigger

work as expected checking for $len($1) is unneeded.
Only case it would be needed is if you want to check if it excists
if ($len($1)) and you want to allow 0 and $false being passed.

Did you miss this bit "I often check for these possabilities, be it needed or not in the particular instance" ?