WoWInterface - Enabling and disabling oUF elements

WoWInterface (https://www.wowinterface.com/forums/index.php)

- oUF (Otravi Unit Frames) (https://www.wowinterface.com/forums/forumdisplay.php?f=87)

- - Enabling and disabling oUF elements (https://www.wowinterface.com/forums/showthread.php?t=40238)

Enabling and disabling oUF elements

I need some help to understand how this actually works or what exactly is self:DisableElement supposed to do and where and how should we use it.

Say I have a custom DebuffHighlight element. Do I have a way to disable other DebuffHighlight elements provided I know theirs names?

I'll just start with what I think I know so far (I'll take the default oUF threat element as example):

An element registers itself with oUF through oUF:AddElement("name", update_func, enable_func, disable_func)

An element enables itself when its prerequisites are met (i.e. self.Threat is not nil)

oUF:AddElement creates an entry in a table called elements for every registered element that looks like this:

Code:

["element name"] = {

        update = update function of the element

        enable = enable function of the element

        disable = disable function of the element

}

We have another table self.__elements which contains the update functions of the enabled elements for the current unit frame(self). This gets populated by initObject() by calling self:EnableElement with every element name from the elements table.

Well when I run

Code:

print(self:IsElementEnabled("Health"))

from within my layout (at the end of the style function as I think that is the point where all element are enabled and applied), I expect it to return true and the index in the table where the update function is found. It returns nothing.

When I run

Code:

print(#self.__elements)

I expect it to return the number of update function, thus the number of used elements for the current frame. When ran from the layout this always returns 1.

I thought then that I should run this from an element itself. print(#self.__elements) then returns another number so I suppose that's the way to go, but how do I know in what order the element are loaded. By the numbers it returns a can tell that not all elements used in the layout are loaded before my print call.

I kinda lost myself, hope someone could shed some light on it for me :)

I don't have an answer to your initial question offhand, but in my layout, before enabling my custom DebuffHighlight element, I check for the presence of other plugins that I know create a similar element. If the user has one of them enabled, I assume they want to use that instead of the functionality built into my layout, and don't enable mine. As long as your layout isn't incompatible with those plugins (eg. they don't require support from the layout, or you added the 2-5 lines of code to support them) then I think that's a better way to go than forcibly overriding the user's choices.

Thanks for the reply Phanx. I just looked at oUF_Phanx. From your dispel element you do

Code:

if select( 4, GetAddOnInfo( "oUF_DebuffHighlight" ) ) then return end

I don't try to enforce my choice on the user, one could still make this a config option and let them deside. But lots of people install oUF layouts just to test them, often without deactivating standalone elements required by the layouts they used before. And this leads to support issues. Yes, I could change the elements names (i.e. self.MyThret instead of self.Threat) but would prefer to use the same layout code for the element and let them choose. I though self:DisableElement would be the easy way to do this, but wasn't able to find out how to use this.

Elements aren't enabled on layouts until after the style function has been called. The basic call sequence for oUF is:
1. Call :Spawn()
2. Override the frames metatable with the oUF proxy version.
3. Do basic setup of the frames functionality (event, update, etc).
4. Call the style function.
5. More setup stuff.
6. Iterate over the registered oUF elements and attempt to enable each and every one of them on the frame.
7. Iterate callbacks and run them on the frame.
8. Disable Blizzard frames and do the last bit of unit specific setup.
9. Return the frame

What you could do, is check for the existence of the elements you want to disable/enable through a callback, as these are called after the elements have been registered.

The callback system is actually leftovers from the time before oUF had a element system, but it won't be removed as it still serves a proper purpose to layouts and external modules.

Does this mean that all elements are registered before the callback? I then have to reenable the other element as else the events get unregistered by the disable function of the element. Is this correct? Would it be possible to post a code example for a callback. Thank you very much for your reply.

1. yes
2. events are registered on a per function basis. One element unregistering shouldn't effect another.
2. no
3:

Code:

oUF:RegisterInitCallback(function(self)

 -- do something with self:w

end)

self is the frame.

oUF_DebuffHighlight won't enable at all if you don't set self.DebuffHighlightBackdrop, self.DebuffHighlightBackdropBorder, or self.DebuffHighlight. Couldn't you just name your custom object self.DebuffHighlightCustom instead?

@haste
Thank you very much

@Saiket

Quote:

Originally Posted by Rainrider (Post 237837)

Yes, I could change the elements names (i.e. self.MyThret instead of self.Threat) but would prefer to use the same layout code for the element and let them choose. I though self:DisableElement would be the easy way to do this, but wasn't able to find out how to use this.