This forum is a read-only archive of the Gammon Software forum (2000–2026). No new posts can be made. Search the archive.

gauges on top of right-click menu hotspots on top of drag handlers

Posted by Fiendish on Sun 14 Nov 2010 09:24 AM — 16 posts, 66,889 views.

Fiendish USA Global Moderator #0
I want to be able to designate a drag handler region for use with left-click only and have the exact same area do something else, like pop up a menu, when right-clicking.

But when I specify another hotspot area for right-clicking, the drag handler doesn't work.

And then when I create a gauge somewhere within the right-clicking hotspot, the right-clicking doesn't work in the area covered by the gauge.

Maybe I'm not thinking straight and it's easier than I remember, but is this doable?
LezChap #1
If I'm remembering correctly, only one hotspot works in any area at a time...example:

If your plugin creates HotSpotA which covers the whole window and drag handles on left click, and then creates HotSpotB which covers the top half of the window and opens a WindowMenu on right click, the top half will no longer respond as a drag handler for the left click.

Hope that helps you experiment and figure things out.
Fiendish USA Global Moderator #2
LezChap said:

If I'm remembering correctly, only one hotspot works in any area at a time

Grumble.
I guess I'll have to look into extending movewindow if I want to use it for this.
Nick Gammon Australia Forum Administrator #3
Fiendish said:

And then when I create a gauge somewhere within the right-clicking hotspot, the right-clicking doesn't work in the area covered by the gauge.


A particular rectangle on the screen is only one hotspot (like, a variable only holds one value).

The evaluation order is alphabetic by hotspot name, so you can control which takes precedence. For example, the "movewindow" handler puts "zz" in front of the hotspot name for the move-drag area, so that if you put something on top of the move area (eg. a close box) then the other hotspot takes precedence.

But if you want to have hotspots do one thing on a left-click but share right-click behaviour, you just have to design that in. For example, in my new-version plugin:

http://www.gammon.com.au/forum/?id=10733

Note that in there, there is a single "mouseup" function. That uses the hotspot ID to switch to the appropriate handler. Now if you wanted to handle RH-clicks differently, then it could switch to a different handler for RH-clicks (or a shared handler, like your proposed menu).

eg.


-- here if they mouseup on a hotspot

function mouseup (flags, hotspotid)

  if bit.band (flags, miniwin.hotspot_got_rh_mouse) ~= 0 then
    
    -- handle RH click here

    return
  end -- if RH click


  -- LH click here

  local f = hotspot_functions [hotspotid]
  if f then
    f (flags, hotspotid)  -- call handler
  end -- function found

end -- function mouseup


You hardly need to "extend miniwindows" to handle a simple case like this.
Amended on Sun 14 Nov 2010 07:15 PM by Nick Gammon
Fiendish USA Global Moderator #4
Nick Gammon said:

Note that in there, there is a single "mouseup" function. That uses the hotspot ID to switch to the appropriate handler. Now if you wanted to handle RH-clicks differently, then it could switch to a different handler for RH-clicks (or a shared handler, like your proposed menu).

eg.


-- here if they mouseup on a hotspot

function mouseup (flags, hotspotid)

  if bit.band (flags, miniwin.hotspot_got_rh_mouse) ~= 0 then
    
    -- handle RH click here

    return
  end -- if RH click


  -- LH click here

  local f = hotspot_functions [hotspotid]
  if f then
    f (flags, hotspotid)  -- call handler
  end -- function found

end -- function mouseup


You hardly need to "extend miniwindows" to handle a simple case like this.

Extend movewindow, not extend miniwindows. Movewindow doesn't currently allow specifying a mouseup handler for the hotspot that it creates.
Nick Gammon Australia Forum Administrator #5
Good point. Looks like I skimmed again. :)
Fiendish USA Global Moderator #6
Nick, mind taking a look?
http://code.google.com/p/aardwolfclientpackage/source/diff?spec=svn57&r=57&format=side&path=/trunk/MUSHclient/lua/movewindow.lua

What do you think? It lets you pass in an external mouseup handler through movewindow.install
Nick Gammon Australia Forum Administrator #7
Why set up this extra variable?


 if mouseup_handler ~= nil then
   external_mouseup_handler = mouseup_handler
 end


And what troubles me is that the RH-click (mousedown) will trigger the moving operation, even though later you are planning to detect the mouse-up and do something else.

I'm tempted to add a check for LH-mouse in the mousedown, or change it a bit more. For example, have external handlers for both mouseup and mousedown, and in that have the handler decide whether to take the default (ie. move the window) or do its own processing (eg. Ctrl+LH click) and then not allow the window move.
Fiendish USA Global Moderator #8
Nick Gammon said:

Why set up this extra variable?


 if mouseup_handler ~= nil then
   external_mouseup_handler = mouseup_handler
 end


It works and seemed necessary at the time. If you can make it work without that, I don't have any love for extra variables. :)

Quote:
And what troubles me is that the RH-click (mousedown) will trigger the moving operation, even though later you are planning to detect the mouse-up and do something else.


I've already worked out a fix for that...except there's a bug (missing feature?) in WindowDragHandler where dragmove and dragrelease callbacks don't get passed which button is being held down, so while I can check in mousedown that the left button has been used and ignore it otherwise, I can't currently check in the dragmove and dragrelease methods.

I added in some print statements and see this (the fields are "methodname entry/exit flags" :
mousedown tried 32
dragmove tried  0
dragmove success  0
dragmove tried  0
dragmove success  0
dragmove tried  0
dragmove success  0
dragmove tried  0
dragmove success  0
dragrelease tried  0
dragrelease success  0
mousedown tried  16
mousedown success  16
dragmove tried  0
dragmove success  0
dragmove tried  0
dragmove success  0
dragrelease tried  0
dragrelease success  0

Now the dragmove and dragrelease methods should be seeing flag values other than 0. The dragmoves and dragrelease in this case should not have any successes for mousedown 32.

I suppose a workaround would be to persist the flags from the mousedown.
Amended on Sun 14 Nov 2010 11:32 PM by Fiendish
Fiendish USA Global Moderator #9
Here. Take a look.

http://code.google.com/p/aardwolfclientpackage/source/diff?spec=svn59&old=44&r=59&format=side&path=%2Ftrunk%2FMUSHclient%2Flua%2Fmovewindow.lua
Nick Gammon Australia Forum Administrator #10
Do you still need the "friends" stuff? Maybe we can simplify things a bit.
Fiendish USA Global Moderator #11
Hmm. Now that we can nondestructively resize, I don't know. I'm not personally using it anymore, but it still seems useful. Also I hate removing backwards compatibility.
Amended on Mon 15 Nov 2010 07:19 AM by Fiendish
Nick Gammon Australia Forum Administrator #12
Well, first things first. I amended the code to remember which mouse was clicked:

https://github.com/nickgammon/mushclient/commit/80c3097929
Nick Gammon Australia Forum Administrator #13
I've done a more general solution. See:

https://github.com/nickgammon/mushclient/commit/d4d5dac

Also see the release notes:

http://www.gammon.com.au/scripts/showrelnote.php?version=4.70&productid=0

This effectively lets you trap and preprocess all the mouse-related events for the movewindow hotspot, and either choose to handle it yourself, or fall back to the default, which moves the window around.

For example, you might handle yourself the RH-mouse click.
Fiendish USA Global Moderator #14
I think you need to change the release notes slightly.


if bit.band (flags, miniwin.hotspot_got_rh_mouse) then


has undesirable functionality.

I think it needs to be

if bit.band (flags, miniwin.hotspot_got_rh_mouse) ~= 0 then
Nick Gammon Australia Forum Administrator #15
Thanks!

Fixed now. The funny thing is, I was thinking "I mustn't fall for that old trick" ... but I fell for it.