[Addon Dev] Blizzard Frames, override?

[Falls]

Ok, so i've been looking at a few addons seeing how they replace the default WoW UI. All seem to do Frame:Hide(). I was thinking this isn't a very memory effective way, especially if you dont intend to use the frame at all. I've been messing around with this, what i found is even when you hide the frame it still calls its update functions. Atleast this is the only way i can explain getting an error from the update function when i set the frame to nil.

I'm still learning how the UI works and Addons in general. What i want to know has anyone ever done something like set the frame to nil, then setting the frame attributes, hopfully overriding any function pointers still in memory. If anyone has, what all needs to be overriden?

I'm still a little uncertain about the Ui, to really try this myself atm. From my meagre attempts, i believe AddOns are loaded after blizzard ones. All the functions are global, this means we can even replace them with functions of the same name? Not sure on that LUA scope im still a little unsure of.

[Axtroz]

Yes, you can override blizzard's functions with your own, just set them to something else, e.g an empty function. Mind that some of them are required to return something or you'll get a bunch of errors but maybe you can start there. My chat filtering addon overrides ChatFrame_OnEvent and it works great for me.

[Falls]

Oh, so you got Blizzards Chat to call your function on update, and your function does its thing then calls the original Blizzard function. I forget you can do this without pointers, as east as funcX = funcY.

[Renew]

overwriting/hooking a function because "i dont need it" is a bad idea...dont do it

[Falls]

overwriting/hooking a function because "i don't need it" is a bad idea...don't do it

It would be nice if you gave a reason. Thinking more about it i think i agree. My reasoning is, if everyone started doing the same, it would become a point where each addon tries to take over the frame causing issue. That and it may break other addons, especially if you start sending it to false functions etc..

Is there some other reason, i should take into consideration?

[modernist]

I've been messing around with this, what i found is even when you hide the frame it still calls its update functions.

this shouldn't be the case. hiding a frame will always stop an OnUpdate script for it being run. if i wanted to hide a frame i would usually do:

Code: Select all

local f = frame
f:Hide()
f:UnregisterAllEvents()
f:SetScript('OnShow', nil)


[Renew]

overwriting/hooking a function because "i don't need it" is a bad idea...don't do it

It would be nice if you gave a reason. Thinking more about it i think i agree. My reasoning is, if everyone started doing the same, it would become a point where each addon tries to take over the frame causing issue. That and it may break other addons, especially if you start sending it to false functions etc..

Is there some other reason, i should take into consideration?

There is no blizzard frame/function that is causing performance problems or take much of performance(esp. Everything that is not in a OnUpdate function)..., you are not coding for a uC
Also you never know what other addons the user will use, hooking functions is always a risk that another addon will become uncompatible with the new function..."deleting" a function is even worse in that way

I've been messing around with this, what i found is even when you hide the frame it still calls its update functions.

this shouldn't be the case. hiding a frame will always stop an OnUpdate script for it being run.

this is right! - a frame:Hide() will stop the OnUpdate function of the frame

[LYQ]

I confirm regarding OnUpdate, but I'm kinda unsure about Events - maybe he means the OnEvent related updates.
Does OnEvent get cancelled like OnUpdate when you call frame:Hide() ?
I never tried or read something about that
I've always created my events on "invisible" but not hidden frames so I really don't know

[modernist]

I confirm regarding OnUpdate, but I'm kinda unsure about Events - maybe he means the OnEvent related updates.
Does OnEvent get cancelled like OnUpdate when you call frame:Hide() ?
I never tried or read something about that
I've always created my events on "invisible" but not hidden frames so I really don't know

events will still fire when the frame they're registered to is hidden i believe — hence my additional suggestion of UnregisterAllEvents() (or specific unregisters if you still want some to pass) in the above post.

[Dreez]

I confirm regarding OnUpdate, but I'm kinda unsure about Events - maybe he means the OnEvent related updates.
Does OnEvent get cancelled like OnUpdate when you call frame:Hide() ?
I never tried or read something about that
I've always created my events on "invisible" but not hidden frames so I really don't know

events will still fire when the frame they're registered to is hidden i believe — hence my additional suggestion of UnregisterAllEvents() (or specific unregisters if you still want some to pass) in the above post.

if the frame registers the events OnLoad they will still fire even if the frame is closed