For those of you who wanted a clickable LibQTip, there is now LibQTipClick.
It's the first alpha commit and I consider it somewhat hackish, but it works and is a hell of a lot better than writing a LibQTip cellprovider (and the required implementation functions) for every cell you want to be clickable.
I've included the latest (alpha-bugfix) version of LibQTip with it, so it should work out-of-the-box by adding LibQTip and LibQTipClick to your AddOn's ToC.
Interesting. Could this be used as a replacement for Dewdrop? :p Actually, that would require being able to show the tip on clicks rather than hover, but whatever. :P
Interesting. Could this be used as a replacement for Dewdrop? :p Actually, that would require being able to show the tip on clicks rather than hover, but whatever. :P
Looks more like a Tablet replacement. Now someone needs to do one for Dewdrop :p
Could actually be either. You can set an OnEnter(), OnLeave(), and OnMouseDown() for each cell. For a DewDrop replacement, you'd set the OnEnter() of the appropriate cell to create/anchor a frame and so on.
torhal, while at work i can't actually look at the code, but please tell me you put in some sort of frame reference so that one could write a generic OnClick handler? Akin to the "info" arg for Ace3?
As I said: The library is on its initial alpha commit so I'm definitely open to adding features as long as they make sense and aren't fluff. Example: As of this moment, there is support for OnMouseDown() but not OnMouseUp() - is there a reason to support both?
No, because the cells are not Button widgets - they're Frames. Unless I'm completely misunderstanding what you're saying.
Probably. The best example i can give is in CBH & Blizzard frames to an extent. In CBH the call back passes the event that triggered it so you can in effect write 1 function to handle 2 or 3 events that all sort of do the same thing. Idea is that if one sets up using this libary stub can you write one generic function for all the OnClicks and using the passed args determine what to do with the click with out diving into the guts of the frame or lib.
IE this is bad =
[php]
function Cell_OnClick(?frame, ?down, ...?)
local txt = frame.button.lable:GetText()
if txt == "var1" then
addon:var1()
elseif txt == "var2" then
addon:var2()
end
[/php]
where this is better:
[php]
function Cel_OnClick(frame, txt, uniqueID, ect ideas...)
if type(addon[txt]) == "function" then
addon[txt](addon, txt, ...)
end
end
[/php]
where the pass values to the OnClick function provide nearly everything you will need to determine what was clicked and be able to in a smart way handle it with out diving into objects and doing a :GetText() each time.
torhal, while at work i can't actually look at the code, but please tell me you put in some sort of frame reference so that one could write a generic OnClick handler? Akin to the "info" arg for Ace3?
You never said anything after I posted the link to the current version of the API, so I was wondering: Is there something more I could do or does it currently do what you'd want?
You never said anything after I posted the link to the current version of the API, so I was wondering: Is there something more I could do or does it currently do what you'd want?
Well your example is quite simplistic... however did not answer the question.
[php]
tooltip.func.OnMouseDown = function(self) DEFAULT_CHAT_FRAME:AddMessage("I hate mice.") end
[/php]
The method you use for delcaring the function is ugly btw.. IMO i'd take a pointer from the AceGUI methods and use their format it's much ncier.
--AceGUI's method in general
--this is what the addon using the lib would do
tooltip:SetCallback("OnClick", function(button, text, uniqueValue) ... end)
Tho AceGUI uses a modified CBH to do all their call backs. But if you do go that route, it's about 20 lines of code to implement? and you reall have to do is fire a call back into the regestry for your frame scripts like so:
--This would be code inside the lib, not code using the lib
local function safecall( tbl, func, ...)
local sucsess, error
if type(tbl) == "table" and type(func) == "string" then
sucsess, error = pcall(tbl[func], ...)
elseif type(tbl) == "function" then
sucsess, error = pcall(tbl, func, ...)
end
if not sucsess then
geterrorhandler()(error.."\n"..debugstack())
end
end
function Frame_OnClickHandler(frame, button, ?...)
safecall(frame.func, "OnClick", "OnClick", frame, button, frame.uniqueValue, ?...)
-- ^tbl ^funcName ^Event ^args
end
if your frame handlers where implemented like this, you'd be able to use 1 function to handle all of the Clicking on the tooltip and not have to have a bajillion functions for each cell.
Sadly i did not have the oppertunity to examine the lib code while at home last night ... will definately do so tonight.
Though I agree a better way to provide callbacks has to be found, I do not think this thread will be hindered by your absence given how constructive your feedback is.
Also, I did say in the initial post that I considered the current implementation to be hackish. As in, I was not happy with it in its current state even though it works as intended. Hence, the need to make a thread asking for opinions, etc.
The problem with that implementation is the fact that there is no way to directly set a function on a given cell. It does handle the one-function-for-all-cells case nicely, but requires the user to do:
local function myHandler(cell, event, ...)
local text = cell.fontString:GetText()
if text == "Button1" then
DoSomething()
end
end
...in order to specifically do one thing with the cell.
I'm suffering from a head concussion at the moment, so I'm not planning on doing anything with this very soon.
It's the first alpha commit and I consider it somewhat hackish, but it works and is a hell of a lot better than writing a LibQTip cellprovider (and the required implementation functions) for every cell you want to be clickable.
I've included the latest (alpha-bugfix) version of LibQTip with it, so it should work out-of-the-box by adding LibQTip and LibQTipClick to your AddOn's ToC.
Looks more like a Tablet replacement. Now someone needs to do one for Dewdrop :p
Probably. The best example i can give is in CBH & Blizzard frames to an extent. In CBH the call back passes the event that triggered it so you can in effect write 1 function to handle 2 or 3 events that all sort of do the same thing. Idea is that if one sets up using this libary stub can you write one generic function for all the OnClicks and using the passed args determine what to do with the click with out diving into the guts of the frame or lib.
IE this is bad =
[php]
function Cell_OnClick(?frame, ?down, ...?)
local txt = frame.button.lable:GetText()
if txt == "var1" then
addon:var1()
elseif txt == "var2" then
addon:var2()
end
[/php]
where this is better:
[php]
function Cel_OnClick(frame, txt, uniqueID, ect ideas...)
if type(addon[txt]) == "function" then
addon[txt](addon, txt, ...)
end
end
[/php]
where the pass values to the OnClick function provide nearly everything you will need to determine what was clicked and be able to in a smart way handle it with out diving into objects and doing a :GetText() each time.
You never said anything after I posted the link to the current version of the API, so I was wondering: Is there something more I could do or does it currently do what you'd want?
Well your example is quite simplistic... however did not answer the question.
[php]
tooltip.func.OnMouseDown = function(self) DEFAULT_CHAT_FRAME:AddMessage("I hate mice.") end
[/php]
The method you use for delcaring the function is ugly btw.. IMO i'd take a pointer from the AceGUI methods and use their format it's much ncier.
Tho AceGUI uses a modified CBH to do all their call backs. But if you do go that route, it's about 20 lines of code to implement? and you reall have to do is fire a call back into the regestry for your frame scripts like so:
if your frame handlers where implemented like this, you'd be able to use 1 function to handle all of the Clicking on the tooltip and not have to have a bajillion functions for each cell.
Sadly i did not have the oppertunity to examine the lib code while at home last night ... will definately do so tonight.
Eww.... Atleast now I know I can just ignore these libs from now on and ignore the threads.
I would suggest something like this: http://ace.pastey.net/104360
It is drycoded and far from being failsafe but it does not create lots of closures and tables. Sample usage:
:P @ Arrowmaster
Agreed. >.<
It's ironic that point of his statement is more applicable to his feedback than to what he was referencing. >.<
There is a constructive part in the same post but you did not quote it. Well, maybe I added it just after you replied.
The problem with that implementation is the fact that there is no way to directly set a function on a given cell. It does handle the one-function-for-all-cells case nicely, but requires the user to do:
...in order to specifically do one thing with the cell.
I'm suffering from a head concussion at the moment, so I'm not planning on doing anything with this very soon.
Erm, I was actually referring to AM's post, not yours. :P