mIRC 7.51 - a variety of possible bugs with /echo switches.

The echo command without -m and -n flags does not make switchbar / treebar colour change to the "event" colour regardless of whether /echo is running in an event or not.

To reproduce:

1. /query x1 - opens a query window - button colour black
2. /echo x1 test - button stays black
3. /echo -m x1 - button turns "message" colour
4. switch to window and back to clear colour
Using a remote with "on *:signal:echotest: echo $1-":
5. /signal echotest x1 test - button stays black (even though this is now an event)
6. /signal echotest -m x1 test - button turns "message" colour.

I also tried this using Text, Action, Join, Part and Quit events with the same result.

I don't believe /echo is supposed to change the highlight of windows based on the event it's called from. That said, I have no idea what -n is supposed to do.

If your switchbar 'Event' color is red, like mine, then /echo will turn it from black to red. If you use /echo -n, it would remain black. Of course, if the color is already blue for 'Message' or green for 'Highlight' then it wouldn't change either way.

Protopia, is there a different effect depending on whether your query window is minimized or just clicked away from? And does it matter whether or not your windows are maximized or in a smaller window? I'm getting your observed behavior with /signal only when the target window is not minimized, which should still be considered a bug.

Using the 7.51 beta in win7-32, i do the following commands:



If status window is a non-minimized non-maximized window, @abc switchbar icon gets the message or event color, depending on whether -m is used or not.
However if I first maximize the status window to full screen, then both windows get the message/event color depending on whether -m is used. In mirc 6.35, both windows would change to the appropriate color, and do it regardless whether status window was maximized or not.

Protopia, check if your query window gets colored when you minimize it and not just click away to another active window. Also, it seems to have the same effect as minimizing the target window if i use a timer to delay the echo to @xyz until mIRC is not the active app, even if status window isn't maximized.

I get the same results whether windows are minimised or not.

P.S. I have reverted your experimental example on WikiChip because IMO we should work out how mIRC works and document it on WikiChip not use WikiChip to post experimental code in the guise of an example.

Cannot reproduce: button text changes to blue (7.51)

But do you get the same result when Status Window is *maximized*?

//window -ax "Status Window"
vs
//window -ar "Status Window"

This means that /echo -m text will process the text as if it was an incoming user message, ie. a PRIVMSG in a query/channel window. Anything that is not a PRIVMSG is an event, eg. join/part/mode/etc. It has nothing to do with script events.

Ok - I think I have it sussed now.

My event colour was dark blue which is barely distinguishable from black when it is switchbar text.

So, as far as I can tell, if text is black, /echo without -m turns it "event" coloured, /echo with -m turns it "message" coloured, but /echo no -m does not turn it back to "event" colour.

So -n only stops it turning "event" coloured.

@Khaled: Is that how it is supposed to work? Is there any way to change the colour back or change it without an echo?

That is how the color is handled normally as well: the message color trumps the event color, and the highlight color trumps the message color. For example:
- person joins a channel: button text turns blue
- person types something: button text turns red
- person leaves channel: button text stays red (as opposed to turning blue again)

You can use /window -gN to set the color explicitly.

Yes you can change the switchbar icon to one of the 3 highlight colors:



Also, note: related to my issue mentioned up-thread, where echo did not color the switchbar icon unless either the active window was +x maximized or the target @window/#channel was -n minimized, I'm finding the same resistance to coloring the switchbar icon using /window -gN under the same conditions, which possibly means that my earlier bug report about "echo -m" is really about "window -gN" if echo's -m switch is using window -g1.

For me, this will change color for @abc:



This will not change color for @abc:



I haven't yet found someone else having this same problem who also used the beta, so I don't know if it's because i'm using win7-32. The bug happens whether or not I have /remote on or off:

//echo -a $os $version $beta $md5($mircexe,2) $file($mircexe).sig $alias(0) $script(0) $dll(0) $com(0) $remote

gives me:
7 7.51 60 3b4e26e8247d366ed6e7a413aba4ec42 ok 1 7 0 0 0

Edit: forgot to mention that i exited and restarted mIRC and the same bugged behavior remained.

A couple of questions:

1. ACTION and CTCP are based on PRIVMSG: do they count as incoming user messages?

2. Are NOTICE based messages (i.e. /notice, /ctcpreply) in a query/channel window considered incoming user messages in the same way?

What does -m implies exactly ? Incoming privmsg would apply stripping option for example, the -m switch does not do that. What is concretly done by -m that isn't done without -m, except the coloring of the bar item ?

AFAIK -m, -n or neither are only to do with switchbar / treebar colouring (like /window -gN).

Obviously mIRC processing of PRIVMSGS has several steps, one of which is colouring the switchbar / treebar. By having /echo -r or using $strip allows script writers fine control over different aspects.

Update: I did a fresh install of mirc 7.51 into a fresh folder, and this series of commands enabled echo -m to highlight the @abc window in red like it's supposed to. I then quit that fresh mirc and copied the mirc.ini from the mirc folder where it wasn't turning red, and the bug reappeared.

So now i get the fun task of pasting changes from the 'bad' mirc.ini until i get the problem to show up again.

Edit: Turns out it was the unchecked mirc-options/display/always-highlight-on-message. So, without that box checked, echo -m only highlights when mirc considers the window to not be visible - either from the active window being a different window that's maximized, or if the target window is minimized, or if mirc isn't the active App.