Suggesting some kind of "ON MIRCTEXT" EVENT to handle window messages generated by the client itself, which would allow a script to monitor them for content, so they could ^HALT them or take action based on their content.
There are some settings in mIRC where there's not an identifier call to find the value, but the setting can be found in mirc.ini [options], but those aren't officially documented for new scriptors to find them, and in some cases would force the script to issue a /saveini to make sure the $readini value is correct. But there are other things where you can't peek at disk to see the setting.
This would be easier and more accurate than trying to inspect the status window from the bottom-up looking for content without actually being able to confirm that this was a message created by the client instead of created by something else like /echo /loadbuf /filter.
I'm seeing this as a 'catch all' event to handle all the text that's not something that can be handled by intercepting 'raw' or other events. If it's not something generated by 'raw' or some other event where the info can be obtained, it would trigger this instead.
Depending on what happens when you use a silencing dot for commands like /.dcc passive, a script can see the setting for something without the message being displayed, if the event handler has some kind of $shown identifier returning $true or $false, to indicate whether the text can actually be seen.
One use case for this would be for situations like the problem I encountered related to this thread
https://forums.mirc.com/ubbthreads.php/topics/270577/new-play-switchesI was helping fix someone else's script, where they were using /play to send significant amount of text to channel, but when the /play stop command was issued, it kept sending output to channel because several lines were queued in the flood que. I didn't want to just clear the que too, because there's no way for the script to know how many of the lines in the que were for this script vs other text. Also, as far as I know, other than looking at the output from the /flood command, there's no other way to find how many lines are in the flood buffer. So instead I used the /flood command to send the message to the status window, from where I could use
$gettok($line(status window,$line(status window,0)),-6-,32)
to get the content of the last line in the status window, to show a message to channel telling how many lines were pending in the que. It worked fine for me, but not for the person I was helping, and it took a while to figure out there was different behavior because they didn't have the line separator deleted, so the last line of their status window was a "-" instead of being the message I was looking for.
Other use for this would be things like detecting the reconnect 'retry #N' message text showing to screen, so a script could take action based on what was (or was not) happening.
Possibly the most common use for this would be - if the midnight "Session Time:" were also echoed to the status windows - this would be an easy way for scripts to be triggered every midnight without the complications of trying to do this with a timer, where there would also be the risk that something could ruin it with /timer* off. If the decision were that the Session Time message would be shown only to the status window, it would be easy for a script to use this event to hook that Client Message and echo it to the open channels and queries.
This would be for 'real' client messages, so something showing up because of reloading a logfile shouldn't count. It also is for client messages, and not for the expected output for commands. So all lines of /filter output should not trigger it, but the error message for /filter -sw @mirc * should.
Since this is a grab-bag event, it would be up to the script to have an appropriate text match for the thing they're looking for, but I can't think of any cases where 2 unrelated things would return the same text string.
