Forums Bug Reports $mouse.x bug?

Hi all,

For some reason, //echo -a $mouse.x with return a * /echo: insufficient parameters error when the mouse is over a non active dialog, in the channel switch bar or basically on any part of the screen that isnt active in mirc, toolbar etc etc.

Is this a bug?

This is *probably* by design-- but you'd expect a response in dialogs

(Disregard previous GetCursorPos() comment)

That's what .dx/dy are for. .x/y are supposed to return the x,y coords relative to window/dialog under the cursor (edit), so it makes sense to return $null when the mouse isn't above a mirc window/dialog.

Well it seems .x/y doesn't work at all outside of events in dialogs, active or not. That is not consistent with the way it works in windows.

Hi,

no this is not a bug.

if you do //echo -a 4
you will get the same message.
What you are doing here is telling mirc to use a color, then you miss the rest of the text.

Kind Regards

ote=_cornflake_]Hi all,

For some reason, //echo -a $mouse.x with return a * /echo: insufficient parameters error when the mouse is over a non active dialog, in the channel switch bar or basically on any part of the screen that isnt active in mirc, toolbar etc etc.

Is this a bug? [/quote]

Did you even try that?

//echo -a 4 works perfectly fine. //echo 4 doesn't, but /echo with any switches and then a number does.

You have it backwards: the colour is *before* the -switches, never after.