Forums Bug Reports $mouse.win returns Status Window on signal

When a signal is sent it makes the $mouse properties become Status Window's.

A similar issue was reported in the past, https://forums.mirc.com/ubbthreads.php/ubb/showflat/Number/250619/ so this is probably the same issue

I think it is and if so I think the documentation should be worded differently. As of right now version 7.43 the mIRC.chm file states:



So it should return the active window's properties, not the properties of the window related to a current event.

Note that if you remove the -n flag the script behaves as "expected".

It certainly seems like odd behavior, but /signal -n is an explicit flag to evaluate mid-event, at which point window state may be inconsistent.

In other words, $mouse.win may actually be returning the correct "active window" at the time of evaluation, but because of event processing order, mIRC might have temporarily changed the active window for other reasons. It probably shouldn't be doing this, but the workaround is simple enough, and you typically shouldn't need -n.

I would suggest that the problem here isn't the documentation for $mouse, but the undocumented side-effects of the -n flag in /signal.

If there is a good reason for this to be done internally, the simple scripters we are can only see this as a very annoying behavior.
You can't just tell him he doesn't need -n, it might be true, but he might also have given a simple version of what he is doing to show the issue, perhaps he has heavy operations following the /signal command and he does want -n, where waiting for the end the script execution is not an option.

In the original report with $wid, $window().wid could be used as an easy workaround but in the case of $mouse, it's not that easy because he does not take a window parameter.

I agree the documentation of $mouse isn't the problem, but nor is -n in /signal, $mouse.win inside an on text event triggering inside #test, completely unrelated to signals, would fail the same ($mouse.win should not be returning #test but the current active window at the time, according to $mouse.win doc): any operation made inside an event which is relying on 'window' will fail.


The undocumented behavior is that mIRC triggers almost all events with the status window set as the active window, a similar analogy is how $1 etc are used in $regsubex to handle the subtext special markers, mIRC steals your $1- for a short period of time, so short it's undocumented!, here mIRC steals your active window before restoring it as well. I think it's not documented to keep things simple, eventually the few scripters puzzled about it will be answered here.

The help file says $mouse is about 'mouse event', so I think that part should be reworded, it works outside the menu { event.. The workaround he needs is $window().prop, passing the window's name $menu in /signal -n

Indeed. I would put it like this: the fundamental issue here is that /signal, including /signal -n, does not pass on event-related identifier values to the signal handler. As another example, if you use "/signal -n" from "on TEXT", you'll find that in the corresponding "on SIGNAL" code, $chan returns nothing and $nick returns your own nick. For someone who does not realize this, I think that documenting that $mouse also works outside events is not going to be of much help, even though it is a good idea anyway. This is simply an issue with rather misleading symptoms. As Wims mentions, the solution is to pass the desired event values as parameters to /signal.

/signal -n not passing local identifiers of an event to the on signal event is a different issue than what is being reported here, it does not explain it, otherwise $mouse.win would be $null (but as I said $mouse isn't a local identifier).
This report is only explained by what Khaled stated, that events use the status window as the 'active' window.

Hmm I disagree. This may be an issue only Khaled can answer, but what I think is going on here, is that since the local $mouse.* event information is not passed on to "on SIGNAL", the global $mouse.* identifier returns information about what mIRC sees as the current window - which, for signals, happens to be the status window (*). The fact that there is a difference between local and global information can be seen by doing "/window -a <someotherwindow>" from the "menu {}" script code: while this will change the value of $active, it will not change the value of $mouse.win. This in contrast to an event that itself does not have mouse data, where activating another window will change not only $active but also $mouse.win!

Note that from "on TEXT", $mouse.win is not necessarily set to "Status Window" either.

(*) However the thing that makes me doubt everything I said, although it also doesn't support your alternative theory :), is that $active is still "@test" from the signal handler. At this point I'm no longer convinced that there is no bug at all here, though.

Well yeah, only Khaled can tell at this point, but I don't buy the argument there is a local $mouse and a global $mouse, to me it's just a global $mouse relying on a variable representing the active window.
That's a good point but perhaps there is a small check, checking if it's inside a menu event {, in which case mouse.win is made to return the value of the window triggering the event.
$active being @test inside the on signal event is weird though, there are definitely some dispecrancies in the way mIRC report the active window accross identifiers

That is the case. In all events, some event-specific values are made available during the event. Outside of the event, these default to global or no values.

The $active identifier is different and has always returned the actual active window.