I don't want to set the scale. I want to set the width and height of every unitbutton controlled by the header.
Something like this would work:
local setSize = [[
local parent = self:GetParent()
local width = parent:GetAttribute("width")
local height = parent:GetAttribute("height")
local function SetSize(header,width,height)
for k,v in ipairs(header) do
local func = header:GetAttribute("initialConfigFunction")
if not func then
func = setSize
elseif not strfind(func,setSize) then
func = func..setSize
Setting the width and height of the header is a bit of a strange way to go, since if you then apply any background or border to it, it'll only surround one frame, and if you anchor other frames to it, they won't be in the expected location.
I'm also not sure why you're setting initial config functions multiple times; are you working with frames whose creation you don't directly control? If not, you should just put all of you "set up this frame" stuff in one place.
Here's how Grid (essentially) does it:
local frame = self[#self]
frame:RegisterForClicks("LeftButtonUp", "RightButtonUp", "MiddleButtonUp", "Button4Up", "Button5Up")
local header = self:GetParent()
if header:GetAttribute("unitsuffix") == "pet" then
If you wanted to add stuff to the initial config function from multiple places, you could just set up a table of functions, and then loop through and call them all from the InitializeFrame method.
Ah. Well, Grid is "precreating" all of its frames, because there are currently some bugs on Blizzard's end with lettings headers dynamically create frames in combat. Here's how Grid forces the header to create all its frames up front:
local maxColumns = header:GetAttribute("maxColumns") or 1
local unitsPerColumn = header:GetAttribute("unitsPerColumn") or 5
local startingIndex = header:GetAttribute("startingIndex")
local maxUnits = maxColumns * unitsPerColumn
if not header.UnitFramesCreated or layoutGroup.UnitFramesCreated < maxUnits then
header.UnitFramesCreated = maxUnits
header:SetAttribute("startingIndex", - maxUnits + 1)
I'm not really sure; ask MSaint, and/or whoever is maintaining PitBull4 these days... it's using the same hack. I didn't have time around the patch release to actually look into the issue in detail myself.
I get sRaidFrames errors dealing with frame creation all the time if I'm in combat when somebody else joins the raid. That's why I used to hide them completely (but see its ticket #32). There's typically no error if I'm the one joining a group; either all the raidframes are properly shown, or none of them are and I /reload after I get out of the fight.
I believe there is a bug in the SecureGroupPetHeaderTemplate. When you neither chose useOwnerUnit nor filterOnPet it will add "pet" to the unitid a second time. But this has nothing to do with creating frames in combat.