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.