The easiest way I found to make the fonts and everything in the tooltip bigger or smaller is to use tooltip:SetScale()
I normally do it just before the tooltip:Clear() that precede code that add the lines to the tooltip. In your case I would try:
tooltip = libQTip:Acquire("AltGuildTooltip", 3, "LEFT", "LEFT","RIGHT")
tooltip:SetScale(1.1) -- put the value in a var for your options if you want
And I would not bother with the fonts at all. If you really want to use fonts, you can check the code in Syllabus. If I remember correctly, you should to create your font ahead of time and then use it with SetFont(). There used to be a bug with CopyFontObject() so you should probably avoid it.
Well, just wanted to say that I had very similar problems in Syllabus then inthedrops had. In my case though, none of the LibQTip workarounds were needed (or even working). What did the trick is to stop using CopyFontObject and set the font parameters by hands just like in the example from inthedrops.
I have other addons that use LibQTip but did not have the issue. None of them are using anything but the default fonts.
I have a little issue with my OnEnter function that set a tooltip. An image is worth a thousand words (or so they say):
Notice in particular the little funky effect where neither tooltip is above the other.
Here's the code for my OnEnter funtion:
local function ShowSkillTooltip(line, arg, button)
if arg then
tooltip:SetLineScript(line, "OnEnter", ShowSkillTooltip, skill.spell_id)
tooltip:SetLineScript(line, "OnLeave", function() GameTooltip:Hide() end)
I think that if I was using a QTip tooltip for the spell, the placement would take care of itself but I really need the normal tooltip function and doing a SetSpellByID() on QTip Tooltip didn't work in my limited tests.
So, anyone has an idea for me to try? Thanks in advance.
Your call to rawset() does nothing, since its target is "table", which is a non-existent variable (and also a Lua object type), the variable "index" doesn't exist and is therefore nil, and the value you're trying to set is "button" which, if you actually need to use rawset(), should be the target.
table and index are placeholder names for the first two arguments that LUA passes to __index. They are assign in function (table,index). I did this just to give a name to the frame so I could debug while I was understanding your example. That __index function is actually never called and the frame is always created in ShuckItProvider:AcquireCell(tooltip). I lift the AquireCell from your code rather then your example. I guess I should have cleaned up the cell prototype.
When I use /spew on ShuckItProvider.cell after I get the error, I see that the InitializeCell and other functions of the prototype are set properly for the cell. What I don't have are the function that are normally define for the button like SetScript. It's like cell is no longer a frame after setmetatable is applied.
I'm starting to thing that secureframe prevent the setmetable somehow. I'll try with normal frame tonight.
I'm trying to get the cell provider thing to work and so far, my problem seams elsewhere.
Here is my AcquireCell (debugging code included)
--local cell = table.remove(self.heap)
self.cell = table.remove(self.heap)
if not self.cell then
local cell_name = "ShuckItSecureButtonHeap"..tostring(#self.heap)
self.cell = setmetatable(CreateFrame("Button", cell_name, UIParent, "SecureActionButtonTemplate"), self.cellMetatable)
and here's my InitializeCell
if InCombatLockdown() or IsStealthed() or busy or
(not IsOpenable(shuck_bag, shuck_slot) and not IsAClam(shuck_bag, shuck_slot)) then
Print(L["Nothing to do or in combat"])
frame:SetAttribute( "type1", "macro" )
frame:SetAttribute( "macrotext1", "/use "..self.bag.." "..self.slot)
if InCombatLockdown() then return end
frame:SetAttribute( "type1", ATTRIBUTE_NOOP )
frame:SetAttribute( "macrotext1", nil)
self:SetScript("OnEnter", function(frame, ...)
self:SetScript("OnLeave", function(frame, ...)
Anyways, my problem is that when InitializeCell is called, self is not a frame (secure or otherwise) so the SetScript method fails.
ShuckIt-30200-1.26\ShuckIt.lua:402: attempt to call method 'SetScript' (a table value)
ShuckIt-30200-1.26\ShuckIt.lua:491: in function `AcquireCell'
After much debuging and poking around, it seams that the setmetatable command modify the frame and only the methods from cellPrototype can be called. None of the method normally associated with a frame (like SetScript) are available.
Hmmm... I'll have to check a bit more then. What Ara did appear to be working and the SecureActionButtons have a normal frame (kind of like the LibQTip tooltip) as a parent. That's what gave me the idea of using a secure cell provider.
I don't need to have the tooltip active in combat, I just want to have a out of combat clickable tooltip that won't get blocked. Right now I need a hiden secure frame that is activated by doing /click SecureFrameName. The only other solution except for Ara's that I've seen is to have a floating secure button that eats away on the UI real estate. I'm trying to find something that fits better in a data broker context.
world of hurt, yes, because everything from the initial mouseover to the button u click has to inherit a secure attribute. Can't really do that with LDB as most (read all) display's don't use secure buttons initially. Anchoring to an insecure frame can cause issues.
What is the issue with anchoring to an insecure frame? I basically trying to do a "secure" tooltip like Ara Broker WeaponBuffer is doing.
Hi Torhal, any headways on the SetScale() issue? Just wondering if you found anything or if there is something else I should test.
New question: anyone tried to use a Home brew CellProvider to create secure frames? I want to use some macros when clicking on the tooltip of one of my addons. I wondering if I'm looking at a wolrd of hurt trying to do this with LibQTip or if someone has tried it. Any advices?
1: Don't save your anchor frame - pass it every time you draw the tooltip, because some people are weird and run multiple displays with the same feeds.
I guess there is a possibility that the user can mouse over a new AllPlayed LDB icon directly from the tooltip but in that case I should receive a new EnEnter and the new anchor should be saved. I basically did what you did in TravalAgent except that I do not supply the saved value with my OnUpdate function. which is the only time I do not supply the Anchor.
I believe I need the anchor to redraw the tooltip when it needs to be updated without a new OnEnter/OnLeave pair of events. I guess I could simply not use SmartAnchorTo if no anchor was provided.
2: Don't run your own tooltip-hiding OnUpdate(), unless you really like maintaining this on your own. I suggest that you look at the API docs for :SetAutoHideDelay(), which will also properly release the tooltip.
I'll look into that. Is there a way to have a callback when a tooltip is release? I would need it to stop my tooltip update timer.
3: Drawing the tooltip in its entirely from an OnUpdate() is insanely wasteful. Instead, keep track of the lines and columns that require the updates and use :SetCell() on them in your OnUpdate(). If you need an example, look at nanoTalk's code.
I'll have a look but I tried it is the past and since there are multiples ways that the values are totaled, it's quid of complicate for something that is not really suppose to happen. LDB doesn't have a detach tooltip. Your comment made me realized thought that I did not sync the tooltip refresh with the data update which is throttle to 1 second when the seconds are displayed or 20 seconds when only the minutes are displayed.
After I solve the memory issue of point 4., I think I'll be at ease with a bit of CPU waist that should not happen when you are doing anything important. I mean, who is looking at the total time played when in combat? :-)
4: Re-use your tables. You're creating a large amount of throwaway tables and if someone mouses in-and-out of the tooltip you're creating that many every time, making garbage-churn inevitable - especially with your current method of refreshing the values in the tooltip by repeatedly re-drawing it (this is generating roughly 3KiB per second).
That is something that I most definitely need to take care off. Thanks for pointing it out. The lack of throttling made this very mush apparent.
Thanks for your help and your suggestions, very much appreciated.