The SuggestionIt seems strange that for every other event, we use the format "on *:....", but with mouse events we have to use a menu definition. This is inconsistent, can be quite confusing, and is quite cumbersome(especially with picture windows) depending on what the user wishes to do. I am of the belief that if it is an event it should use the event syntax, and leave the menu definition syntax for defining menus.
So I now suggest a depreciation of using a menu definition to handle mouse events in exchange for:
on *:MOUSE:@Win:Event:x[-x2]:y[-y2]:{
; This triggers when a specified mouse event occurs within an area
;
; @win - the window inwhich the mouse event is to take place.
;
; Event - the mouse event that is to take place. The events being:
; enter - the mouse entered the specified area
; move - the mouse moved within the specified area
; sclick - the left mouse button was pressed
; dclick - the left mouse button was pressed twice
; rclick - the right mouse button was pressed
; uclick - a mouse button was unpressed
; lbclick - an item in the listbox was selected.(This will trigger reguardless of the specified area)
; drag - the mouse moved while a mouse button was held
; drop - the mouse button was released after a drag took place
; wheelup - the mouse wheel was rotated upward
; wheeldown - the mouse wheel was rotated downward
; leave - the mouse exited the specified area
; You can specify multiple events by seperating them with a camma. You may specify * for all events
;
; x[-x2] - the X range for which the event will trigger. * may be specified for the entire width of the window
; y[-y2] - the Y range for which the event will trigger. * may be specified for the entire heighth of the window
}
With the previously stated format the $mouse identifier should be updated with the following additions:
$mouse.event - The mouse event that took place
$mouse.dragx/y - the x,y position relative to the window inwhich the drag and/or drop originated.
$mouse.delta - the number of units the mouse wheel moved. A negative delta signifies the wheel spun upward.
The ExampleFrom the following example, you can see the required code is simpler and easier to read.
Scenerio: You want to fill a rectangle when the mouse enters it, then revert it's color back to the window background when it leaves while only (re)drawing when and what needs to be.
alias exp1 {
window -aBCdfp @Exp1 0 0 250 250
drawrect @Exp1 1 1 100 100 50 50
exp1_color
}
;-----------------------;
;-- CURRENT WAY --;
;-- --;
menu @exp1 {
mouse:exp1_color
}
alias exp1_color {
if ($inrect($mouse.x,$mouse.y,100,100,50,50) != %exp1) {
set %exp1 $v1
drawfill @Exp1 $iif($v1,04,$color(background)) 1 125 125
}
}
on *:CLOSE:@Exp1:unset %exp1
;-------------------------;
;-- SUGGESTED WAY --;
;-- --;
on *:MOUSE:@Exp1:Enter,Leave:100-150:100-150:{
exp1_color
}
alias exp1_color {
drawfill @Exp1 $iif($inrect($mouse.x,$mouse.y,100,100,50,50),04,$color(background)) 1 125 125
}
The NotesIf two scripted mouse-event-handlers with in the same script match the specific event, only the first within the script will trigger. This is normal mIRC behavior, but thought it should be mentioned
;If this triggers:
on *:MOUSE:@Win:sclick:1-50:1-50:echo -a $mouse.event on $mouse.win @ $mouse.x $mouse.y
;This will not:
on *:MOUSE:@Win:sclick:1-100:1-100:echo -a $mouse.event on $mouse.win @ $mouse.x $mouse.y
if my suggestion is implemented, the current way to do mouse events should remain viable but it's documentation removed from the helpfile and replaced with documentation of the a fore mentioned. This is to stem the use of the old format.
Comments/Questions/Additions/Flames are all welcome