I'm interested because I have addons that hook tooltips too and I also don't have the time to check every addon in your list, so I figured asking you is the fastest way! :p
Well forgive me I don't know the answer without googling and downloading them and checking, the code is a couple years old, and most of those addons I don't use myself, guess I'll have to find some time to go through them all and see which of them are still alive. But hey I found one, thats enough right?
Well, your method of hooking CreateFrame() and then checking if the frame returned is of type GameTooltip, and then checking the name of the frame against a list of known addon (and their used gametooltip names) isn't any better.
You say you have a better solution of correctly hooking dynamically created tooltips that don't have an API? I'm all ears.
If you already have a list of addons you are comparing the name of the tooltip frames against, you should already know if you need to securehook CreateFrame or not (answer: you don't - because LinkWranger is the only one you support which create tooltips dynamically).
Wrong, LinkWranger far from the only addon that creates tooltips dynamically, LibTipHooker supports quite a few more of them if you care to check yourself.
Actually I think the behavior is intended, and correct. The bug is that self:GetItem() doesn't return the crafted item, or both items. We bitched at the blues to fix that a few times, but I've kinda stopped caring. Double info on recipe tips doesn't really bother me.
*edit* and taint should *never* be an issue with tooltips... but still the script handler is better than direct hookerage.
It's not better if you need to workaround the recipe glitch. Like I said, depends on what you are trying to do.
You're right that it's not always the same fontstring, but it's not an empty line, it's a vertical offset. You could probably find a (very expensive) way to check this in a safe way.
The sole purpose of "OnTooltipSetItem" is to allow hooking, whatever the setting function is, whatever the parameters order and type that are called on all methods that creates tooltip, if it IS an item, then the "OnTooltipSetItem" callback is called. The fact that it's called twice is a implementation bug.
You can try to tweak around this bug and you should ask for the bug to be fixed. The issue with pre-hooking is that you need to know all functions that set a tooltip and hook them all. It needs to be maintained. You also have to care about not tainting.
I remember reporting this on the official forums way back when this feature was first introduced in a TBC patch, but they don't seem to care and its still broken on 3.2 PTR.
Also with the new GetItemStats(itemlink, table) API in 3.2, its also nearly useless in its current state. I wonder why it would only accept itemlink as input if it doesn't consider gems or enchants, it should just accept itemId which doesn't work in the current build, you have to feed it a proper itemlink.
You are mistaken. Mendeleev does post hooks of OnTooltipSetItem and OnTooltipCleared and it works perfectly when both the recipe and the item the recipe creates are in the local cache. I don't remember what happens when one isn't in the cache though, but if it does misbehave it will be correct the next time the tooltip is shown.
The top line in your screenshot is from the second call not the first.
What are you smoking? The hooks are still called on every tooltip even if you use the hook-all-methods method.
What are you smoking? The hooks are still called on every tooltip but without the extra lines of code to check if its the first call or second. And with out the OnTooltipCleared hook call. And with out the extra code if you want to check for recipes. ...
PS: I don't normally respond to rude posts. I know its kinda your style of talking, but please learn to not speak like you understand something when obviously you don't got a clue.
local tt_OnTooltipSetItemOrSpell = function (self)
local is_a_recipe = self:NumLines() > 4 and select(5, _G[self:GetName().."TextLeft4"]:GetPoint(1)) < -2
local count = (self[ArkInventory] or 0) + 1
self[ArkInventory] = count
if (not is_a_recipe and count == 1) or (is_a_recipe and count == 2) then
local tt_OnTooltipCleared = function (self)
self[ArkInventory] = nil
local function HookTooltip(tt)
for _, tt in ipairs(tooltip_frames) do HookTooltip(tt) end
This is assuming TextLeft4 is always an empty line for recipes, which is not the case.
The question is why not avoid the overhead when you can?
In my OnTooltipSetItem script, I simply set a flag, such as tooltip.myaddon = true, and check if this flag is present so that the script doesn't add the line twice on recipes.
You then do an additional hook for OnTooltipCleared(I think that's the handler's name) to nil out tooltip.myaddon.
Unless I'm mistaken, if you add the line on the first call, it adds the line directly below the "item" made by the recipe, which ends up in the middle of the tooltip instead of the end, most likely not what you want.
As shown in this image, if you blocked the second call, only the first "ItemLevel: 85" line would be shown.
Secondly, using the OnTooltipSetItem method means extra checking on every item tooltip you show, not that you will show a lot of tooltips very often, but the overhead is there. While the hooking-all-methods method is a one time thing on load.
As for LinkWrangler, the author has provided a callback system which you can register with for LinkWrangler to inform your addon when it has created new tooltips (on demand) for you to apply your hooks or add your addon's lines.
Yes, thats just one addon, what about those that don't have one and you/your users would want support for it.
In the end LibTipHooker solves all of the above problems with a wide range of support for other addons.
1. OnTooltipSetItem gets called twice on recipes, if your addon needs to work well with recipes then this method may not always work for you. This is why LibTipHooker hooks all SetXItem methods instead.
2. Do you or your users need support for other addon tooltips? Do you only need it to work with the default UI? LibTipHooker maintains a list of most popular tooltip addons for you.
3. What about dynamically generated tooltips, for example LinkWrangler or Links gives you as many ItemRefTooltips as you need, do you want to support these? LibTipHooker does.
Of course, everything starts out small, with a small user base, maybe you don't need/want to support something you don't use yourself, so any of the hooking methods mentioned in previous posts will work well for you, RatingBuster started with small simple hooking too.
But when you break millions of downloads support is something you will get a lot of requests for, and thats when the whole thing became big enough for RatingBuster to spawn the LibTipHooker.