I'm currently updating my actionbar mod and had a pretty frustrating time trying to adpet the first actionbar/bonusactionbar. It just didn't work out when it comes to combat. So I searched around and tukz already had something to work with.

I tried it yesterday and what you need is this pretty much this. This will handle the complete first bar.

But how is the reference between the default buttons and the new bar being made? I see "SetFrameRef", "Execute" and "SetAttribute("_onstate-page"," but actually I don't understand what they do.

Code:

local button
for i = 1, NUM_ACTIONBAR_BUTTONS do
button = _G["ActionButton"..i]
self:SetFrameRef("ActionButton"..i, button) -- creates frame "ActionButtonX" reference in secure environment
end
self:Execute([[ -- executes the snippet in the secure env
buttons = table.new()
for i = 1, 12 do
table.insert(buttons, self:GetFrameRef("ActionButton"..i))
end -- creates new table in secure environment and fills it with action button frames retrieving them by frame reference
]])
self:SetAttribute("_onstate-page", [[
for i, button in ipairs(buttons) do
button:SetAttribute("actionpage", tonumber(newstate))
end -- State driver updates "page" attribute based on macro conditionals. "_onstate-page" is called and newstate contains new actionbar page number.
]])

what i fail to understand is why would you do something like that to default action bars. they're already doing this... Because of damn taint probably

what i fail to understand is why would you do something like that to default action bars. they're already doing this... Because of damn taint probably

It is for overriding Blizzard's default paging with some custom paging. Example: A priest has offensive spells on page 1 and heals on page 2. Custom paging is implemented so that ALT changes page 1 to page 2 and page 2 to page 1. If the ALT key was down without those SetAttribute calls while on page 1, all of the priest's spells would now be the heals from page 2 but still show the icons for the offensive spells from page 1.

Now the reason why Blizzard's code doesn't need to do that is because it updates the button visually via OnEvent in response to registered events while SecureStateDriver updates during OnUpdate. Since OnEvent is processed before OnUpdate, any state change made will not be picked up so you must force the update manually via a SetAttribute call in the secure environment since the OnAttributeChanged script also triggers a visual update.