Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ Miniwindows
➜ gauges on top of right-click menu hotspots on top of drag handlers
gauges on top of right-click menu hotspots on top of drag handlers
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
Pages: 1 2
Posted by
| Fiendish
USA (2,534 posts) Bio
Global Moderator |
Date
| Sun 14 Nov 2010 09:24 AM (UTC) |
Message
| 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? |
https://github.com/fiendish/aardwolfclientpackage | Top |
|
Posted by
| LezChap
(36 posts) Bio
|
Date
| Reply #1 on Sun 14 Nov 2010 05:40 PM (UTC) |
Message
| 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. | Top |
|
Posted by
| Fiendish
USA (2,534 posts) Bio
Global Moderator |
Date
| Reply #2 on Sun 14 Nov 2010 06:43 PM (UTC) |
Message
|
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. |
https://github.com/fiendish/aardwolfclientpackage | Top |
|
Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
Date
| Reply #3 on Sun 14 Nov 2010 07:11 PM (UTC) Amended on Sun 14 Nov 2010 07:15 PM (UTC) by Nick Gammon
|
Message
|
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. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Fiendish
USA (2,534 posts) Bio
Global Moderator |
Date
| Reply #4 on Sun 14 Nov 2010 09:18 PM (UTC) |
Message
|
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. |
https://github.com/fiendish/aardwolfclientpackage | Top |
|
Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
Date
| Reply #5 on Sun 14 Nov 2010 09:21 PM (UTC) |
Message
| Good point. Looks like I skimmed again. :) |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Fiendish
USA (2,534 posts) Bio
Global Moderator |
Date
| Reply #6 on Sun 14 Nov 2010 10:18 PM (UTC) |
Message
| 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 |
https://github.com/fiendish/aardwolfclientpackage | Top |
|
Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
Date
| Reply #7 on Sun 14 Nov 2010 11:19 PM (UTC) |
Message
| 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. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Fiendish
USA (2,534 posts) Bio
Global Moderator |
Date
| Reply #8 on Sun 14 Nov 2010 11:22 PM (UTC) Amended on Sun 14 Nov 2010 11:32 PM (UTC) by Fiendish
|
Message
|
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. |
https://github.com/fiendish/aardwolfclientpackage | Top |
|
Posted by
| Fiendish
USA (2,534 posts) Bio
Global Moderator |
Date
| Reply #9 on Sun 14 Nov 2010 11:46 PM (UTC) |
Message
| 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 |
https://github.com/fiendish/aardwolfclientpackage | Top |
|
Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
Date
| Reply #10 on Mon 15 Nov 2010 05:51 AM (UTC) |
Message
| Do you still need the "friends" stuff? Maybe we can simplify things a bit. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Fiendish
USA (2,534 posts) Bio
Global Moderator |
Date
| Reply #11 on Mon 15 Nov 2010 06:48 AM (UTC) Amended on Mon 15 Nov 2010 07:19 AM (UTC) by Fiendish
|
Message
| 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. |
https://github.com/fiendish/aardwolfclientpackage | Top |
|
Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
Date
| Reply #12 on Mon 15 Nov 2010 08:47 PM (UTC) |
Message
| |
Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
Date
| Reply #13 on Mon 15 Nov 2010 09:57 PM (UTC) |
Message
| |
Posted by
| Fiendish
USA (2,534 posts) Bio
Global Moderator |
Date
| Reply #14 on Tue 16 Nov 2010 06:46 AM (UTC) |
Message
| 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
|
https://github.com/fiendish/aardwolfclientpackage | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
47,268 views.
This is page 1, subject is 2 pages long: 1 2
It is now over 60 days since the last post. This thread is closed.
Refresh page
top