The Suggestion
It 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:
Code:
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:
Code:
$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 Example
From 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.
Code:
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 Notes
If 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
Code:
;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

Last edited by FroggieDaFrog; 30/11/11 01:12 PM.
I am SReject
My Stuff