ZO_PlayerInventoryTabs - m_buttonData.control vs m_button

[circonian]

What is the difference between these. I originally thought they were supposed to be the same thing. Am I wrong?

ZO_PlayerInventoryTabs.m_object.m_clickedButton.m_button
-- and
ZO_PlayerInventoryTabs.m_object.m_clickedButton.m_buttonData.control

Just to give you an idea while reading this, this is what the table looks like:

ZO_PlayerInventoryTabs = {
   -- contains stuff and --
   m_object = {
      -- contains stuff and --
      m_clickedButton = {
         -- contains stuff and --
         m_button = <button control>,
         m_buttonData = {
            -- contains stuff and --
            control = <button control>,
         }
      }
   }
}

When your in the backpack they always seem to be the same. If you open the mail, for example, they are no longer the same. The buttons are numbered differently in the mail than they are in the backpack even though its still ZO_PlayerInventoryTabs.
This seems to be because the mail window does not have a quest tab.

When you set a callback for the buttons like:

local function InvTabSwitch(_tButtonData)
   -- do stuff --
end
 
local function HookBankButtons()
    local tButtons = ZO_PlayerBankTabs.m_object.m_buttons
    
    for k,v in pairs(tButtons) do
        local tButtonData = v[1].m_object.m_buttonData
        local hCallback = tButtonData.callback
        
        -- Make the SubMenu bar for this button & store it in tButtonData
        local menuBar = MakeMenuBar(v[1])
        tButtonData.FilterIt_SubMenu = menuBar
        
        tButtonData.callback = function(...)    
                InvTabSwitch(...)                       
                hCallback(...)
            end     
    end
end

It passes m_buttonData to the callback. In the backpack it works fine, since m_buttonData.control & m_button are the same. When the callback is passed m_buttonData it contains control which is the button you pushed...but

When the mail is open because the m_buttonData.control & m_button are not the same and it causes a problem.
Your callback is still passed m_buttonData, but it only contains control which is not the button you pushed. It is the last button you pushed, which I believe is a mere coincidence due to the way the buttons get numbered and the fact that there is no quest tab in the mail window.

So what is supposed to be the difference between m_buttonData.control & m_button.
Why does the backpack pass the callback function the m_buttonData.control for the button that is pushed, but when the mail is open it passes in the wrong m_buttonData.control. Is it just a bug?

So I figured I could just do this to grab m_button which "seems" to be the real button that was pushed.

-- m_buttonData passed to callback
local menuBar = m_buttonData.control:GetParent()
local actualClickedButton = menuBar.m_object.m_clickedButton.m_button

But it leaves me wondering since I don't really know the difference between:

ZO_PlayerInventoryTabs.m_object.m_clickedButton.m_button
-- and
ZO_PlayerInventoryTabs.m_object.m_clickedButton.m_buttonData.control

Is this going to cause me more problems somewhere else?

[The Real Daenerys]

nice work!

[circonian]

Originally Posted by circonian Is this going to cause me more problems somewhere else?

Apparently the answer to that question is yes...

Another side effect of this is that it seems that you can't save a reference to the last button pushed.

If you try to save a reference to, lets say the Armor inventory tab button control, when you open the mail that reference now points to the Weapons button !!!

[merlight]

Just going through the code and writing down findings... ... ... Ok now that I got through it, you can skip down to the bad button
I'll leave the whole journey here, may be useful another day.

The v[1] from tButtons in your iteration is a control created from ZO_MenuBarButtonTemplate1 by default, but different windows override it with their own template (hopefully always derived from the default). The default template's OnInitialized handler calls ZO_MenuBarButtonTemplate_OnInitialized(self). There it creates an instance of class MenuBarButton:

function ZO_MenuBarButtonTemplate_OnInitialized(self)
    self.m_object = MenuBarButton:New(self)
end
 
function MenuBarButton:Initialize(button)
    self.m_button = button
    ...
end
 
function MenuBarButton:SetData(owner, buttonData)
    self.m_buttonData = buttonData
   ...
end

So you can get the object from the control, and the control from the object:

local buttonControl = v[1]
-- this should always be true
assert(buttonControl == buttonControl.m_object.m_button)

m_clickedButton is an instance of MenuBarButton


*** bad button ***

It's quite unfortunate the callback only gets buttonData as the argument. buttonData.control is not coming from the MenuBarButton class, it is set in local function InitializeInventoryFilters(inventory) (ingame/inventory/inventory.lua), i.e. once when the buttons are created. But later, in ZO_InventoryManager:ApplyBackpackLayout, the buttons are released, and some of them acquired from the pool again, but .control is not re-assigned. And that is the problem - buttonData remains the same, but gets attached to a different button control.

It's a bug in ZO_InventoryManager:ApplyBackpackLayout in the loop containing ZO_MenuBar_AddButton calls. Since MenuBarButton class is only accessible via metatables of existing buttons, the simplest fix will probably be replacing ZO_MenuBar_AddButton:

function ZO_MenuBar_AddButton(self, buttonData)
    local button = self.m_object:AddButton(buttonData)
    buttonData.control = button
    return button
end

[Garkin]

This is a little offtopic, but all button data is stored in tabFilters table, so it would be easier to work with this table:

local function InvTabSwitch(_tButtonData)
    -- do stuff --
end
     
local function HookBankButtons()
    local inventory = PLAYER_INVENTORY:GetDisplayInventoryTable(INVENTORY_BANK)
    local tabFilters = inventory.tabFilters
       
    for k,tButtonData in pairs(tabFilters) do
        local hCallback = tButtonData.callback
           
        -- Make the SubMenu bar for this button & store it in tButtonData
        local button = inventory.filterBar:ButtonObjectForDescriptor(tButtonData.descriptor)
        local menuBar = MakeMenuBar(button.m_button)
        tButtonData.FilterIt_SubMenu = menuBar
 
        tButtonData.callback = function(...)
                InvTabSwitch(...)                      
                hCallback(...)
            end    
    end
end

EDIT: As merlight has explained, "buttonData.control" is not supported by MenuBar / MenuBarButton class and it is not correctly updated by inventory manager. So, I have updated code to get button from descriptor.

[circonian]

Originally Posted by merlight Just going through the code and writing down findings... ... ... Ok now that I got through it, you can skip down to the bad button I'll leave the whole journey here, may be useful another day.

Awesome explanation, thanks !

[circonian]

Originally Posted by Garkin This is a little offtopic, but all button data is stored in tabFilters table, so it would be easier to work with this table: local function InvTabSwitch(_tButtonData)     -- do stuff -- end       local function HookBankButtons()     local inventory = PLAYER_INVENTORY:GetDisplayInventoryTable(INVENTORY_BANK)     local tabFilters = inventory.tabFilters             for k,tButtonData in pairs(tabFilters) do         local hCallback = tButtonData.callback                     -- Make the SubMenu bar for this button & store it in tButtonData         local button = inventory.filterBar:ButtonObjectForDescriptor(tButtonData.descriptor)         local menuBar = MakeMenuBar(button.m_button)         tButtonData.FilterIt_SubMenu = menuBar           tButtonData.callback = function(...)                 InvTabSwitch(...)                                       hCallback(...)             end         end end EDIT: As merlight has explained, "buttonData.control" is not supported by MenuBar / MenuBarButton class and it is not correctly updated by inventory manager. So, I have updated code to get button from descriptor.

Ah nice, i tried to find a way to get the button from descriptor but couldn't find a way. Thanks for the info!