AppearanceTooltip/overlays.lua:449: attempt to index global 'Baganator_MainViewFrame' (a nil value)
Quartzfire opened this issue · 7 comments
Hi,
I get this now when logging in to WoW, looks like a clash with the integration with Baganator.
11x AppearanceTooltip/overlays.lua:449: attempt to index global 'Baganator_MainViewFrame' (a nil value)
[string "@AppearanceTooltip/overlays.lua"]:449: in function `?'
[string "@AppearanceTooltip/overlays.lua"]:21: in function <AppearanceTooltip/overlays.lua:19>
[string "=(tail call)"]: ?
Locals:
baganator_setitemdetails = defined @AppearanceTooltip/overlays.lua:438
baganator_rebuildlayout = defined @AppearanceTooltip/overlays.lua:441
(*temporary) = defined =[C]:-1
(*temporary) = nil
(*temporary) = nil
(*temporary) = nil
(*temporary) = "attempt to index global 'Baganator_MainViewFrame' (a nil value)"
UpdateOverlay = defined @AppearanceTooltip/overlays.lua:61
Interesting - looks like Baganator has started delaying its setup by a frame-or-so, and so I'm trying to hook in slightly too soon. I can fix that.
Thanks, I also raised it on the baganator discord, so can pass the above message on to plusmouse to see what comment he may have?
I figure it's just because of Baganator/Baganator@17e1194 or the related commits before it, which probably just wound up delaying its calling of Baganator.UnifiedBags.Initialize() by a tick. Anyway, it's a pretty simple fix on my end.
(What would be nice would be some API on Baganator's end for other addons to call so they could pop up as item adornments -- it's currently special-casing knowing about Pawn and CIMI to pull them in, so things like AppearanceTooltip need to sneak in instead.)
Hi. I work on Baganator.
I've done some work on designing an API for adding a corner option. It needs some work to configure default values so the visuals show up initially when no configuration has been done yet and to scale correctly as at the moment it only scales the corner position, not the widgets too (the internal API does both). I'm planning to use the API internally as well as making it externally available so it should cover most corner use cases.
This API does not work, but getting it complete and working is on the roadmap. Other features are taking priority for now.
function Baganator.UnifiedBags.API:RegisterButtonDataSet(configName, dataCallback, optionalSeparateOptionLocaleText)
function Baganator.UnifiedBags.API:RegisterButtonCorner(cornerValue, localeText, positioningCallback, parentingCallback, autoOptions)So far the API design for usage to add a BoE or BoA label would look like this.
local IsEquipment = Baganator.Utilities.IsEquipment
local qualityColors = {
[0] = CreateColor(157/255, 157/255, 157/255), -- Poor
[1] = CreateColor(240/255, 240/255, 240/255), -- Common
[2] = CreateColor(30/255, 178/255, 0/255), -- Uncommon
[3] = CreateColor(0/255, 112/255, 221/255), -- Rare
[4] = CreateColor(163/255, 53/255, 238/255), -- Epic
[5] = CreateColor(225/255, 96/255, 0/255), -- Legendary
[6] = CreateColor(229/255, 204/255, 127/255), -- Artifact
[7] = CreateColor(79/255, 196/255, 225/255), -- Heirloom
[8] = CreateColor(79/255, 196/255, 225/255), -- Blizzard
}
-- Add any widgets needed for display to the item button
Baganator.UnifiedBags.API.RegisterButtonInitializer(function(self)
if not self.BindingText then
self.BindingText = self:CreateFontString(nil, nil, "NumberFontNormal")
end
end)
-- Hide/remove any icons/text on the widgets so it has no visual, ready for new
-- item data or for being blank with no item set
Baganator.UnifiedBags.API.RegisterButtonClear(function(self)
self.BindingText:SetText("")
end)
-- Add callback per item button when a specific option is enabled
Baganator.UnifiedBags.API.RegisterButtonDataSet("show_boe_status", function(self, data)
if IsEquipment(data.itemLink) and not data.isBound then
self.BindingText:SetText(BAGANATOR_L_BOE)
local color = qualityColors[data.quality]
self.BindingText:SetTextColor(color.r, color.g, color.b)
end
end)
-- Add a widget for the corner to the dropdown for the icon corner settings.
Baganator.UnifiedBags.API.RegisterButtonCorner(
"binding_type",
BAGANATOR_L_BINDING_TYPE,
function(self, targetCorner, targetCornerNotScaled, fontSize)
self.BindingText:ClearAllPoints()
self.BindingText:SetPoint(unpack(targetCorner))
local font, originalSize, fontFlags = button.BindingText:GetFont()
self.BindingText:SetFont(font, fontSize, fontFlags)
end,
function(self, widgetParent)
self.BindingText:SetParent(widgetParent)
end,
{"show_boe_status",},
)
local function IsBindOnAccount(itemLink)
local tooltipInfo = C_TooltipInfo.GetHyperlink(itemLink)
if tooltipInfo then
for _, row in ipairs(tooltipInfo.lines) do
if row.type == Enum.TooltipDataLineType.ItemBinding and row.leftText == ITEM_BIND_TO_BNETACCOUNT then
return true
end
end
end
return false
end
-- Create a visible option in the Customise dialog
Baganator.UnifiedBags.API.CreateOption("show_boa_status", BAGANATOR_L_SHOW_BOA_STATUS)
-- Add callback per item button when a specific option is enabled
Baganator.UnifiedBags.API.RegisterButtonDataSet("show_boa_status", function(self, data)
if IsBindOnAccount(data.itemLink) then
self.BindingText:SetText(BAGANATOR_L_BOA)
local color = qualityColors[data.quality]
self.BindingText:SetTextColor(color.r, color.g, color.b)
end
end)
@plusmouse That looks workable to me. I'd have to rewrite a few things I'm currently doing in order to pull out the icon-display from the button-overlay-management, but that seems like a reasonable adjustment to make.
Might be worth adding some sort of namespacing on the registrations? In a hypothetical future of widespread support it might be confusing if several different addons all registered something like a "junk" button-corner and overwrote each other (and, even more confusingly, the core Baganator implementations).