/parseline and modes - mIRC Discussion Forums

haltdef'ing in an on RAWMODE doesn't stop mIRC's default mode message from being displayed if it originates from a /parseline command

Code:

on $*:PARSELINE:in:/^\x3A\S+ MODE #\S+ +o \S+:{
  parseline -itn $parseline
}

on ^*:RAWMODE:#:{
  echo # Custom Mode Message; mIRC's default should NOT be shown
  haltdef
}

Even more concerning, is mIRC doesn't apply the mode:

Code:

//parseline -itnqp :example!example@example.com MODE #example +o $me

on ^*:RAWMODE:#example:{
  echo # Custom Mode Message; mIRC's default should NOT be shown
  haltdef
}

Sufficiently related to mention here I think: "on RAWMODE" is also (erroneously) not listed on the "Halting default text" help page.

After further testing, it would appear that the -n switch is the culprit here. I don't know why it allows the default message to take place, that seems to be the bugsee below

But I feel this relates to the usage of -n either being bugged itself, or poorly explained in the helpfile

"-n = add a CRLF to the end of the line if it does not have one." Is it needed for text inputs or bvars only? Or only when we are queuing a new message, etc etc

The original report is correct aswell, parseline + mode changes is bugged, both trigger rawmode/mode/status-mode events AND display the default mIRC even if halted:

Code:

/.parseline -tiqp :test!test@test MODE ##mirc -v foobar
/.parseline -tiqpn :test!test@test MODE ##mirc -v foobar

Disregard
All questions listed here have been raised and answered in this thread

Some of this information, many of us feel, should be in the help file

Originally Posted By: FroggieDaFrog

All questions listed here have been raised and answered in this thread

Some of this information, many of us feel, should be in the help file

I would in fact go so far as to suggest that /parseline's -n not being ignored when combined with -i is still a bug. There is no scenario where one would want a literal CR/LF pair at the end of a single line. Changing that behavior would make changing the helpfile less necessary.

I agree with your statement. This is a bug/oversight in the interface.

After forgetting that mIRC does not delimit by crlf, I (incorrectly) assumed I could use use jscript via coms to format a huge NAMES list, and then use a single /parseline command to inject the messages...

And furthermore the RFC dictates that messages sent or received are terminated by CRLF so at no point should mIRC be assuming that a parse-pending message in the buffer shouldn't terminate at crlf

Originally Posted By: "RFC 1459 - Page 7"

IRC messages are always lines of characters terminated with a CR-LF (Carriage Return - Line Feed) pair

The /parseline -n switch was added as a convenience to scripters when sending messages to a server, to ensure that it ends in a CRLF. I am going to add the words "when sending a message to a server" to the -n description in the help file to make this clear.