I found a curious thing while beating my head on my desk over an error message.
Background: I have coded a small custom window to alert a user that certain things in the topic of a targetted channel window show certain services to be other than 'UP'.
The window is created by code in a raw 332 (or 322 if topic is displayed by a /list command), with service details filled in.
The nick of the user that edited the topic and time of editing, is then displayed via a raw 333 code fragment, thus having to overwrite 2 lines with that info.
A varient of this is On Topic, which also feeds to the 2 display alias codes.
I was trying to surround the messages within the custom window with a box surround effect (I miss the old IBM PC charset with those box effect characters) and thus the use of the $chr(127) detailed below.
The line (spaced out for readability)
/scid %PTMcid //rline -h 5 @ServiceAlert 14 $+( $chr(124) , $chr(32) , %UpdateMsg , %Filler , $chr(124) )
fails with an error message of '* /rline: insufficient parameters (line 440,' etc.
/scid %PTMcid //rline -h 5 @ServiceAlert 14 $+( $chr(124) , $chr(160) , %UpdateMsg , %Filler , $chr(124) )
works quite happily. The only difference is the $chr(32) breing replaced with $chr(160).
I'm guessing that since $chr(124) is the pipe character (|), and when the parser finds a space char, Schr(32), after that, it treats the pair as if it's a command pipe, rather than just two characters.
I'm not looking for any help on this, I just thought it might be useful for people to be aware of it.