$lower() and strings containing commas

$lower(text)
Returns text in lowercase.

//say $lower(One, Two, Three)
* Too many parameters: $lower

why? surely $lower() should just take any string, regardless of whether it contains commas or not...

J

you can use a variable instead. But you are right, the string-handling in mirc-scripts is a bit silly if you know strict languages like C++, tcl and so on.

Because mIRC strings are unquoted it's impossible for mIRC to know whether that's a single string with commas in or whether you tried to give 3 parameters to the identifier. As mths said, simply assign the string to a variable first:
var %tempvar = One, Two, Three
say $lower(%tempvar)

It's better that mIRC behaves in a consistent and future-proof manner like this, instead of making exceptions to when and where commas separate parameters and where they're just part of a string.

Quote:

But you are right, the string-handling in mirc-scripts is a bit silly if you know strict languages like C++, tcl and so on.

I totally agree with you! I don't know strict languages like C++ (I dream about it), but it's truly silly.

That, and the need for [ ] to force mIRC to say "this is a variable, please take note of it!", is the two things I really hate about mIRC Scripting. Otherwise, it's fun and easy scripting language.

Why is it silly? If commas were treated as part of the text how could people use multiple parameters with identifiers (short of making the scripting language use quoted strings and breaking all backwards compatability - now that would be silly)?

Also, brackets aren't needed for mIRC to treat a variable correctly. Brackets are only required when you wish to change the order of evaluation or if you want something to be evaluated more than once.

I have a problem...

Code:

alias get.rate {
  ; once again, I hate [ ]

  var %a $1-
  var %file data\mp3.rate.txt
  if ($chr(44) isin %a) { var %file $remove(%a,$chr(44)) }

  if ($invalid.fname(%a) == 2) { return invalid }

  var -s %b $read( [ %file ] , s, [ %a ] )
  var -s %c $read( %file , s, %a )
  if (!%b) { return null } | else { return %b }
}

If I do a //get.rate $read(data\mp3.rate.txt), it will output this:

Code:

*** Set %b to 8
-
* $read: insufficient parameters (line 421, mp3-2.mrc)

every single time! Line 421 is when it tries to set variable %c. Question; Is there something wrong in my code? In line 420, it works well. When hard brackets surrounds the variables. To me, it seems that mIRC doesn't understand that it is variables there, and doesn't have enough parameters to do the task ($read). It also seems to be a problem when temporary variables are made (/var %var).

Now, does my problem classify as "when you wish to change the order of evaluation or if you want something to be evaluated more than once." ??

This was the quickest example in my script that I could find.

//echo -a $asc(,) <- Happy to know that mIRC is consistent...

Does it work normally if you use the correct syntax for /var (/var %varname = value)?

Quote:

//echo -a $asc(,) <- Happy to know that mIRC is consistent...

- I for one am glad that mIRC is consistent. For many identifiers there is always the possibility that extra parameters could be added, why remove that possibility and make the language inconsistent like that simply because some people can't be bothered to assign a variable first?

You are evil, my friend

Of course did /var -s %c = $read()... work as it should. And I've been using [ ] for years now... argh... Didn't [ ] get introdused in v5.7 ?

I've read the helpfil, and I see "var %x" and "var %x = someting", but I can't see "var %x hehe" - the format I'm always using. That should mean that it isn't supported or correct scripting? consistence...