Remove a Frame element with LUA

[richardCANE]

hi guys

i want to create a frame that shows your main bag's content with icons too...

so when i open up my addon frame the LUA dynamically draws a frame and draws the CURRENT content of my bag into...

is it possible to remove/delete/clear frames, textures and fontstrings ( xml elements ) with LUA somethings like Frame:Delete ?

thanks for any replies

[Torhal]

No, this is not possible. Nor is it possible to give them to the Lua garbage collection facility. What you need to do is create these things once and re-use them as they're needed.

[richardCANE]

thanks for reply

and how to do that? can you give me some little example in LUA? how can i reuse the elements?

[Slakah]

local framepool = {}
 
local function removeframe(f)
    f:Hide()
    tinsert(framepool, f)
end
 
local function getframe()
    local f = tremove(framepool)
    if not f then
        --Create your frame here and assign it to f
    else
        --revert any unique changes you may have made to the frame before sticking it in the framepool
    end
    return f
end

Something like that as a very basic example

[richardCANE]

thank you so much

[maximdewit]

cant you for example simply write frame=nil?

dont shoot me ^^

--

[Seerah]

That nils the reference to the frame, and maybe its properties, but the actual frame object is still in memory.

[Torhal]

Originally Posted by maximdewit cant you for example simply write frame=nil? dont shoot me ^^ --

I have to shoot you. Four posts above yours, I explained that this wasn't possible.

*BLAM!*

[Sythalin]

But you can reduce the memory allocation by stripping the variable of it's data with f={}.

[Akryn]

Originally Posted by ChaosInc But you can reduce the memory allocation by stripping the variable of it's data with f={}.

That's still just re-pointing the pointer, it's not even as good as f=nil.

[nightcracker]

And what about table.wipe(f) ?

[Torhal]

That does nothing for frames but clear their table members. The frame itself still exists, and will always exist until the UI is reloaded or you re-start WoW. Tables CAN be garbage-collected. Frames, though they are a special form of table, CANNOT.

[nightcracker]

Originally Posted by Torhal That does nothing for frames but clear their table members. The frame itself still exists, and will always exist until the UI is reloaded or you re-start WoW. Tables CAN be garbage-collected. Frames, though they are a special form of table, CANNOT.

So basicly the closest you can get is like this:

local function deleteframe(f)
    if not f.DeletedEvent then
        f.DeletedEvent = f.OnEvent
        f:Hide()
        f.OnEvent = function() end
    end
end
 
local function restoreframe(f)
    if f.DeletedEvent then
        f:Show()
        f.OnEvent = f.DeletedEvent
        f.DeletedEvent  = nil
    end
end

[Torhal]

No - that requires that you have a frame pointer for restoreframe(), which at that point isn't really possible without breaking the illusion that the frame has been "deleted". You would use this, instead:

local AcquireFrame, ReleaseFrame
do
	local frame_cache = {}

	function AcquireFrame(parent)
		local frame = tremove(frame_cache) or CreateFrame("Frame")
		frame:SetParent(parent)
		return frame
	end

	function ReleaseFrame(frame)
		frame:Hide()
		frame:SetParent(nil)
		frame:ClearAllPoints()
		tinsert(frame_cache, frame)
	end
end	-- do block

I also don't see the purpose in replacing the frame's OnEvent script - perhaps you're thinking of OnUpdate...but that never fires when the frame is hidden anyway.

[nightcracker]

Originally Posted by Torhal No - that requires that you have a frame pointer for restoreframe(), which at that point isn't really possible without breaking the illusion that the frame has been "deleted". You would use this, instead: local AcquireFrame, ReleaseFrame do local frame_cache = {} function AcquireFrame(parent) local frame = tremove(frame_cache) or CreateFrame("Frame") frame:SetParent(parent) return frame end function ReleaseFrame(frame) frame:Hide() frame:SetParent(nil) frame:ClearAllPoints() tinsert(frame_cache, frame) end end -- do block I also don't see the purpose in replacing the frame's OnEvent script - perhaps you're thinking of OnUpdate...but that never fires when the frame is hidden anyway.

Because it might be - for example - registered to PLAYER_REGEN_DISABLED and in the event handler it shows itself, and sets it to a certain point for example? And something is wrong with your frame_cache table, it works fine as long as you work with 1 frame, but with multiple frames you would get the wrong one back from the acquire function.

[Torhal]

Originally Posted by nightcracker Because it might be - for example - registered to PLAYER_REGEN_DISABLED and in the event handler it shows itself, and sets it to a certain point for example? And something is wrong with your frame_cache table, it works fine as long as you work with 1 frame, but with multiple frames you would get the wrong one back from the acquire function.

There is nothing wrong with the code. We were talking about deleting a Frame, which we established was impossible to do.

This code gives you a way to say "I no longer need this frame. Make it go away." while still giving you a way to re-claim it later if it's needed, or a create a new one if there are none currently in the cache. If you want to be sure you're dealing with the same frame every time, why in the hell would you "delete" it and then "reclaim" it? Just hide the damn thing and unregister its events, then un-hide it when you need it to be available again. Also, setting an OnEvent script like this:

        frame:SetScript("OnEvent", function() end)

...creates an empty function which uses memory that must be dealt with later by the garbage collector when it's no longer being referenced whereas simply calling

        frame:UnregisterEvent(PLAYER_REGEN_DISABLED)

or even (though, again, WHY?)

        frame:SetScript("OnEvent", nil)

are both "free" methods and do what you need without pretending that you're deleting a frame which you obviously aren't because you have to have a handle to it to "undelete" it. Always remember: There is no such thing as a magic bullet - things which appear to be usually have hidden caveats.

[nightcracker]

I see, but still I think you should clean up the frame a little bit more, since once you'd want to reuse a frame you get all the rubbish hooked to it. What about this? I'm planning to release it as a lib.

FrameHandler = {
    cache = {},
    scripts = {
        OnDragStart = true,
        OnDragStop = true,
        OnEnter = true,
        OnEvent = true,
        OnKeyDown = true,
        OnKeyUp = true,
        OnLeave = true,
        OnLoad = true,
        OnMouseDown = true,
        OnMouseUp = true,
        OnMouseWheel = true,
        OnReceiveDrag = true,
        OnSizeChanged = true,
        OnUpdate = true,
    },
}
 
function FrameHandler:CreateFrame(parent, name, inherits)
    local parent = parent or UIParent
    local f = tremove(FrameHandler.cache) or CreateFrame("Frame")
    if name or inherits then
        local f = CreateFrame("Frame", name, parent, inherits)
    else
        local f = tremove(FrameHandler.cache) or CreateFrame("Frame")
    end
    f:SetParent(parent)
    f:Show()
    return f
end
 
function FrameHandler:DeleteFrame(f)
    local name = f:GetName()
    f:Hide()
    f:SetParent(nil)
    f:UnregisterAllEvents()
    f:SetID(0)
    f:ClearAllPoints()
    for script, _ in pairs(FrameHandler.scripts) do
        f:SetScript(script, nil)
    end
    if name then
        _G[name] = nil
    end
    tinsert(FrameHandler.cache, f)
end

[Torhal]

I do not see any benefit in having this exist as a library - the caching code is simple and small enough to be included directly within the AddOn. Also, indiscriminately setting all scripts to nil and removing the global name can cause an assortment of issues. If you're making a named frame, or setting scripts to it, you're generally going to want to keep it around so removing either makes no sense. Also, you cannot determine the intent of such a library's users - they may want the ability to safely add and remove frames for a frame factory, but not do all of the things you are doing.

The code I pasted here is ripped from my own LibQTip library, which manages its OWN frames since it knows all the attributes which are set on them. A general-purpose library that attempts to do such a thing will ultimately fail. AddOn A does this:

frame.this_is_awesome = function(self, arg1) DoStuff() end

and then releases the frame to the general-purpose frame-recycling library. AddOn B grabs that frame from the lib's cache, does other stuff to it, and shoves it back when done. After all of this modification and passing around, the frames will end up using more memory overall than a discrete AddOn-specific cache would ever dream of, since it has absolutely no knowledge of what the AddOns that use it are doing to the frames and therefore has no way to properly clean them up.

[nightcracker]

Originally Posted by Torhal I do not see any benefit in having this exist as a library - the caching code is simple and small enough to be included directly within the AddOn. Also, indiscriminately setting all scripts to nil and removing the global name can cause an assortment of issues. If you're making a named frame, or setting scripts to it, you're generally going to want to keep it around so removing either makes no sense. Also, you cannot determine the intent of such a library's users - they may want the ability to safely add and remove frames for a frame factory, but not do all of the things you are doing. The code I pasted here is ripped from my own LibQTip library, which manages its OWN frames since it knows all the attributes which are set on them. A general-purpose library that attempts to do such a thing will ultimately fail. AddOn A does this: frame.this_is_awesome = function(self, arg1) DoStuff() end and then releases the frame to the general-purpose frame-recycling library. AddOn B grabs that frame from the lib's cache, does other stuff to it, and shoves it back when done. After all of this modification and passing around, the frames will end up using more memory overall than a discrete AddOn-specific cache would ever dream of, since it has absolutely no knowledge of what the AddOns that use it are doing to the frames and therefore has no way to properly clean them up.

Your right (damn, sometimes that's really hard to say you know?)

[Torhal]

That's why remembering that there's no such thing as a magic bullet is so important.