Is it normal for an options table to go past 2500 lines, I did the options for the 5 bars I have. And its huge, most of it was just copy paste, then search replace some stuff. If I ever miss a curly bracket I'll never find it.
Sounds normal. :P
Omen's option table itself is nearly half the file. (Yeah I stuffed everything in one file)
You can easily add in toggles that the user can turn on/off at will that controls what your addon does.
[Although using Enable() and Disable() might be easier in many simple addons.]
During OnInitialize(), you can call :SetEnabledState() which tells Ace3 whether the addon (or an addon sub-module) should start in enabled or disabled state. If you called :SetEnabledState(false) for example, OnEnable() will not run. Whether to pass true or false to this in OnInitilize() could just be a value you stored in the savedvars.
That really depends from addon to addon and what it does, and whether a "disable mode" will even make sense.
For the most parts, most addons don't even have a "disabled mode". If you want to disable a addon, you know, you just log out and disable it in the login screen! Very few addons actually support disabling properly because of this, and manually calling :Disable() on them will cause issues. Many programmers likewise don't differentiate between putting code in OnEnable() and OnInitialize().
Well change the contents of your :ProfileChanged() code. Check if your addon is enabled first and if it isn't, don't run SetUnitBarsLayout() and some of the other functions. And of course, make sure those are run in :OnEnable()
-- Register options table with aceconfig and add it to blizz options.
LibStub("AceConfig-3.0"):RegisterOptionsTable("Options", UnitBarOptions, "gub")
UnitBarOptionsFrame = LibStub("AceConfigDialog-3.0"):AddToBlizOptions("Options", MyAddon)
-- Add the Profiles UI as a subcategory below the main options
UnitBarProfilesFrame = LibStub("AceConfigDialog-3.0"):AddToBlizOptions("Profiles", "Profiles", MyAddon)
how do I get the profile options added to an existing tree in "options" so when I do Open("Options") I'll see my tree then see profiles at the bottom?
I don't want to use blizzoptions cause the frame cannot be moved. I looked at dxe whch has a tree but couldn't find childgroups defined anywhere. Moving the options frame is important since this mod is using bars that can be anywhere on the screen and the user will need to see them since the options will make changes in real time and not wait for a button to be pressed.
I'll probably have to figure out how the changes can be undone on cancel though.
Change the respective lines to
UnitBarOptionsFrame = LibStub("AceConfigDialog-3.0"):AddToBlizOptions("Options", "My Addon's Options")
UnitBarProfilesFrame = LibStub("AceConfigDialog-3.0"):AddToBlizOptions("Profiles", "My Addon's Profile Options", "My Addon's Options")
To not use BlizzOptionsFrame, or as a second alternative, you can do this:
If you like what you see from using that command, convert it to a slash command. You shouldn't be using the identifier string "Options" though (you registered the names "Options" and "Profiles" for your option tables), they are way too generic and some other addon could overwrite yours.
It looks like two options tables are being used. One is for /slash commands only and the other is for the GUI.
But why is one using AceConfigRegistry and the other is using just AceConfig. I want to do the same. Have a slash command which I figured out how to do. But only for slash commands. Then have another table thats for the GUI only.
If you check the Ace3 source code, you'll see that LibStub("AceConfig-3.0"):RegisterOptionsTable() calls LibStub("AceConfigRegistry-3.0"):RegisterOptionsTable().
However the former has a optional 3rd argument to create a slash command while the latter doesn't. I probably shouldn't be using AceConfigRegistry-3.0 directly, but its of little consequence in this case.
local cfgreg = LibStub("AceConfigRegistry-3.0")
local cfgcmd = LibStub("AceConfigCmd-3.0")
function AceConfig:RegisterOptionsTable(appName, options, slashcmd)
local ok,msg = pcall(cfgreg.RegisterOptionsTable, self, appName, options)
if not ok then error(msg, 2) end
if slashcmd then
if type(slashcmd) == "table" then
for _,cmd in pairs(slashcmd) do
UnitBarOptions above is your options table. You're telling AceConfig that, hey please refer to my options table as "MyAddon".
UnitBarOptionsFrame = LibStub("AceConfigDialog-3.0"):AddToBlizOptions("MyAddon", "Text To Display")
Here, you're telling ACD to add to the Blizzard options, hey use the table I told you to call "MyAddon" earlier. If you don't like the string "MyAddon" to be used as key (internally, AceConfig uses the string as the key of some table), you can use the string "ILikeThisStringBetter".
The returned frame by AddToBlizzOptions() itself isn't particularly useful, because Ace3 will handle its sizing and internals, you aren't really supposed to mess with it such as show/hide or anything. It's main use is for you to call stuff like this:
on a slash command, for example, so that the options open correctly to that of your addon. if you think you can handle a complicated example, see Omen's lines 1867-1910. Everything beyond line 1910 is the actual option table used (yes its huge).