What about, on the simpler side, support for OnDoubleClick()? :)
There isn't an OnDoubleClick() handler in the wow API. Anything that uses double clicks does so probably with onupdate or such to see if it was clicked again... Though double click has been suggested for the api.
DoubleClick functionality should be pretty easy without resorting to any OnUpdate stuff. I was thinking something like this:
function ldbObj.OnClick()
local clickTime = time();
if(clickTime - lastClickTime <= doubleClickThreshold) then
ldbObj.OnDoubleClick();
end
lastClickTime = clickTime;
end
There isn't an OnDoubleClick() handler in the wow API. Anything that uses double clicks does so probably with onupdate or such to see if it was clicked again... Though double click has been suggested for the api.
There isn't an OnDoubleClick() handler in the wow API. Anything that uses double clicks does so probably with onupdate or such to see if it was clicked again... Though double click has been suggested for the api.
Not true apparently. I thought that might be the issue as well, but Torhal set me straight on IRC. See Tekkub's link :p
I wonder if I could use Zebulac's idea for Fubar2Broker though to simulate OnDoubleClick() FuBarPlugin events via received OnClick() LDB events.
No, you're confusing two conversation threads. The problem is that none of the current LDB displays that I know of listen for the OnDoubleClick() event and pass it on to LDB displays. They just do OnClick OnEnter OnLeave etc.
Well FuBarPlugin-2.0 uses OnDoubleClick, so I know it's possible for LDB to do the same. I'm on the verge of trying to hack it into ButtonBin as a proof-of-concept.
I've implemented OnDoubleClick on my display and like I said its not a big deal. The problem with OnDoubleClick lies with the simple fact that an author must really be careful with it and only use OnClick or OnDoubleClick. IF he opts to use both, then he should handle different kind of buttons for each attribute. If he uses the same (eg Left Click + Alt does this and Left Double Click + Alt does that), then the OnClick func will fire first anyway (along with w/e you specify in OnDoubleClick). So yeah, its doable but a bit clumsy if abused.
Is there a way for LDB plugins to determine which handlers an LDB display implements? I'd ideally like to be able to modify F2B to simulate OnDoubleClick only if the display that calls it doesn't provide a real implementation of OnDoubleClick itself.
Also, is it documented anywhere what the official double click delay threshold is for OnDoubleClick?
Is there a way for LDB plugins to determine which handlers an LDB display implements? I'd ideally like to be able to modify F2B to simulate OnDoubleClick only if the display that calls it doesn't provide a real implementation of OnDoubleClick itself.
Not directly, no, since they only provide data and usually not the actual frame/button objects being used. You can probably implement something hackish by exploiting 'self' arguments being used in OnClick and use :GetScript but there are no guarantees that this will work flawlessly with all displays.
Also, is it documented anywhere what the official double click delay threshold is for OnDoubleClick?
I'm not sure that this is set in stone really. Feel free to play around with it though.
EDIT: to avoid confusion, this is part of a discussion with Funky (to avoid ppl wondering why the plugin does nothing for them :p)
The wrapping stuff is GREAT! No more conflicts with existing scripts! And if the plugin try to wrap a non existing script, the snippets are still called! Even if the associated secure templates are not present, as long as the generic handler is <3 <3 <3
So now, when you enter the secure block (in or out of combat), the consumable list shows, along with your alpha settings, all that without a single code addition on both sides (I simply replaced the SetAttribute lines by WrapScript ones on my side).
In addition, the plugin seems free to wrap about everything and doesnt need to implement specific templates, the generic one or any other will do for every possible scripts. So it could be possible to reduce the spec to just: DO.OnCreate, setting the type attribute to "secure" and letting the display implement whatever secure templates he needs.
What remains is how the display could handle tainting scripts properly. Imagine, for exemple, that you want to allow the secure plugin to use your mousewheel stuff in combat.
I will test that tomorrow, having in mind that the display now has complete control over secure templates.
Is there a way for LDB plugins to determine which handlers an LDB display implements? I'd ideally like to be able to modify F2B to simulate OnDoubleClick only if the display that calls it doesn't provide a real implementation of OnDoubleClick itself.
No, it cannot. The plugin simply exposes its API, and the display checks what's there based on what it knows. Currently, only Titan (that I know of) supports OnDoubleClick(). You could probably hack it into ButtonBin yourself, or ask the author to support it.
Also, is it documented anywhere what the official double click delay threshold is for OnDoubleClick?
According to wowprogramming.com:
Fires when the user double-clicks the button.. The cutoff time between clicks for it to be counted as a double-click is 0.3 seconds. Anything slower will trigger two OnClicks.
I've implemented OnDoubleClick on my display and like I said its not a big deal. The problem with OnDoubleClick lies with the simple fact that an author must really be careful with it and only use OnClick or OnDoubleClick. IF he opts to use both, then he should handle different kind of buttons for each attribute. If he uses the same (eg Left Click + Alt does this and Left Double Click + Alt does that), then the OnClick func will fire first anyway (along with w/e you specify in OnDoubleClick). So yeah, its doable but a bit clumsy if abused.
Will OnClick actually fire if the user double-clicks and OnDoubleClick fires as a result? If so, how many times will it fire, and will it be on the first or second click?
EDIT: to avoid confusion, this is part of a discussion with Funky (to avoid ppl wondering why the plugin does nothing for them :p)
The wrapping stuff is GREAT! No more conflicts with existing scripts! And if the plugin try to wrap a non existing script, the snippets are still called! Even if the associated secure templates are not present, as long as the generic handler is <3 <3 <3
So now, when you enter the secure block (in or out of combat), the consumable list shows, along with your alpha settings, all that without a single code addition on both sides (I simply replaced the SetAttribute lines by WrapScript ones on my side).
In addition, the plugin seems free to wrap about everything and doesnt need to implement specific templates, the generic one or any other will do for every possible scripts. So it could be possible to reduce the spec to just: DO.OnCreate, setting the type attribute to "secure" and letting the display implement whatever secure templates he needs.
What remains is how the display could handle tainting scripts properly. Imagine, for exemple, that you want to allow the secure plugin to use your mousewheel stuff in combat.
I will test that tomorrow, having in mind that the display now has complete control over secure templates.
I tested it with SBC 2.5 and it works great, I don't even need to add secure checks! Awesome!
Will OnClick actually fire if the user double-clicks and OnDoubleClick fires as a result?
Yes.
If so, how many times will it fire
As far as I could see from my tests, 1.
and will it be on the first or second click?
First click triggers OnClick and its code. The second will trigger OnDoubleClick and its code, which is why I said that as long as different buttons are being used, its all right. If the same button is being checked again both events, you need some hackish way to only grab the one you are interested in, which may have implications in some cases (delays aren't always accurate afaik).
Sounds like I can just have FuBar2Broker route OnClick events from the LDB display to both the OnClick and OnDoubleClick handlers in the FuBar addon and not bother with trying to catch or emulate OnDoubleClick at all then, because it sounds like it's not likely that any sane addon is going to try to use both for the same mouse button + keyboard modifier combo anyways.
The only downside would be that if double-clicking was the original input event used by the FuBar plugin, it was probably as a safety feature to prevent accidental clicks.
I gave up on the doubleclick handlers long ago because of this behaviour. Personally I'd only use it if you want an action to happen on double-click but also ensure that nothing happens on single-click.
Using modifiers and right clicks is just easier in the end.
There isn't an OnDoubleClick() handler in the wow API. Anything that uses double clicks does so probably with onupdate or such to see if it was clicked again... Though double click has been suggested for the api.
Incorrect. All Button (as well as CheckButton and LootButton whch are both derivatives) frame types has the "OnDoubleClick" script method.
That is,
button:SetScript("OnDoubleClick", function(self, button) end)
will work. Only problem is, OnDoubleClick will also trigger OnClick as well during the first click. The alternative is your own invention such as...
To implement doubleclick on non-button frames, you will need to hack with OnMouseDown handlers, and use GetCursorPosition() and GetTime().
One of the issue with LDB dataobjects is that actually they can be displayed by several displays. One will rarely uses more that one standalone display addons. Now some addons start to ship with LibDBIcon (integrated minimap LDB display). And you could use MakeRocketGoNow to have gather all launchers. It becomes tedious to enable/disable dataobjects in each displays, not speaking of LibDBIcon that does not provide a default interface to disable it.
Thinking about that, I come to the following solution: have a .displayedBy attribute in the launchers and datasources handled by the displays themselves. The idea is to use this attribute as a lock.
Provided an display addon :
* on initialisation, acquire any dataobjects not already acquired (i.e. .displayedBy == nil) unless it is explictly disabled.
* on .displayedBy change :
- if set to self, display the dataobject,
- if set to nil, acquire the dataobject unless it is explictly disabled,
- if set to anything but self, hide the dataobject and explictly disable it.
Then you can see "weak displays", e.g. LibDBIcon, that would display the datasource only when .displayedBy is nil and without setting it (that way it only display it as a default).
You can also see "'strong displays", e.g. MakeRocketGoNow, that would acquire datasources even if already acquired.
Thoughts ?
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThere isn't an OnDoubleClick() handler in the wow API. Anything that uses double clicks does so probably with onupdate or such to see if it was clicked again... Though double click has been suggested for the api.
function ldbObj.OnClick() local clickTime = time(); if(clickTime - lastClickTime <= doubleClickThreshold) then ldbObj.OnDoubleClick(); end lastClickTime = clickTime; endLIES!
http://www.wowprogramming.com/docs/widgets/Frame/SetScript
Not true apparently. I thought that might be the issue as well, but Torhal set me straight on IRC. See Tekkub's link :p
I wonder if I could use Zebulac's idea for Fubar2Broker though to simulate OnDoubleClick() FuBarPlugin events via received OnClick() LDB events.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAlso, is it documented anywhere what the official double click delay threshold is for OnDoubleClick?
Not directly, no, since they only provide data and usually not the actual frame/button objects being used. You can probably implement something hackish by exploiting 'self' arguments being used in OnClick and use :GetScript but there are no guarantees that this will work flawlessly with all displays.
I'm not sure that this is set in stone really. Feel free to play around with it though.
The wrapping stuff is GREAT! No more conflicts with existing scripts! And if the plugin try to wrap a non existing script, the snippets are still called! Even if the associated secure templates are not present, as long as the generic handler is <3 <3 <3
So now, when you enter the secure block (in or out of combat), the consumable list shows, along with your alpha settings, all that without a single code addition on both sides (I simply replaced the SetAttribute lines by WrapScript ones on my side).
In addition, the plugin seems free to wrap about everything and doesnt need to implement specific templates, the generic one or any other will do for every possible scripts. So it could be possible to reduce the spec to just: DO.OnCreate, setting the type attribute to "secure" and letting the display implement whatever secure templates he needs.
Test it please: http://perso.orange.fr/aranarth/wow/addons/Ara_Broker_Poisons-r3.zip
What remains is how the display could handle tainting scripts properly. Imagine, for exemple, that you want to allow the secure plugin to use your mousewheel stuff in combat.
I will test that tomorrow, having in mind that the display now has complete control over secure templates.
-
View User Profile
-
View Posts
-
Send Message
Project AuthorNo, it cannot. The plugin simply exposes its API, and the display checks what's there based on what it knows. Currently, only Titan (that I know of) supports OnDoubleClick(). You could probably hack it into ButtonBin yourself, or ask the author to support it.
According to wowprogramming.com:
Will OnClick actually fire if the user double-clicks and OnDoubleClick fires as a result? If so, how many times will it fire, and will it be on the first or second click?
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorI tested it with SBC 2.5 and it works great, I don't even need to add secure checks! Awesome!
Yes.
As far as I could see from my tests, 1.
First click triggers OnClick and its code. The second will trigger OnDoubleClick and its code, which is why I said that as long as different buttons are being used, its all right. If the same button is being checked again both events, you need some hackish way to only grab the one you are interested in, which may have implications in some cases (delays aren't always accurate afaik).
The only downside would be that if double-clicking was the original input event used by the FuBar plugin, it was probably as a safety feature to prevent accidental clicks.
Using modifiers and right clicks is just easier in the end.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIncorrect. All Button (as well as CheckButton and LootButton whch are both derivatives) frame types has the "OnDoubleClick" script method.
That is,
button:SetScript("OnDoubleClick", function(self, button) end)
will work. Only problem is, OnDoubleClick will also trigger OnClick as well during the first click. The alternative is your own invention such as...
To implement doubleclick on non-button frames, you will need to hack with OnMouseDown handlers, and use GetCursorPosition() and GetTime().
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThinking about that, I come to the following solution: have a .displayedBy attribute in the launchers and datasources handled by the displays themselves. The idea is to use this attribute as a lock.
Provided an display addon :
* on initialisation, acquire any dataobjects not already acquired (i.e. .displayedBy == nil) unless it is explictly disabled.
* on .displayedBy change :
- if set to self, display the dataobject,
- if set to nil, acquire the dataobject unless it is explictly disabled,
- if set to anything but self, hide the dataobject and explictly disable it.
Then you can see "weak displays", e.g. LibDBIcon, that would display the datasource only when .displayedBy is nil and without setting it (that way it only display it as a default).
You can also see "'strong displays", e.g. MakeRocketGoNow, that would acquire datasources even if already acquired.
Thoughts ?