Any possible/alternative ways to access SV at the top of the file?

[Layback_]

Hi all,

So, the reason that I am trying to access SV at the top of each files is to decide whether the files should be fully loaded or not based on its SV.
(To be honest, I am using AceDB-3.0, but with or without using it doesn't really change the fact.)

The similar approach has been discussed here by Galaxy119 and OP, Seyan777.

Here's some example:

SVTest.toc

## Interface: 70200
## Title: SVTest
## SavedVariables: SVTestDB

core.lua

moduleA.lua
moduleB.lua

core.lua

local SVTest = LibStub("AceAddon-3.0"):NewAddon("SVTest");
_G.SVTest = SVTest;
 
local defaults = {
    global = {
        moduleA = true,
        moduleB = true,
    },
}
 
function SvTest:OnInitialize()
    self.db = LibStub("AceDB-3.0"):New("SVTestDB", defaults, true);
end

moduleA.lua

if not SVTest.db.global.moduleA then
    return;
end
 
local ModuleA = SVTest:NewModule("ModuleA");
 
-- So on...

I'm aware of that the first line of moduleA.lua will cause an error as SVs are, sadly, not loaded yet since "ADDON_LOADED" event is fired after all addon codes are loaded.

Would there be any work around, alternative solution, or any smarter(?) ways to achieve this?

TL;DR - methods to enable/disable module based on SVs

Thank you.

[Lombra]

Well, you will always need to wait for ADDON_LOADED. What I've seen addons do before is wrap the whole module in a function, and then just wait until ADDON_LOADED before calling it. (or not) If you don't need the module to be loadable on demand you can also destroy the function to free up that memory.

[Layback_]

Originally Posted by Lombra Well, you will always need to wait for ADDON_LOADED. What I've seen addons do before is wrap the whole module in a function, and then just wait until ADDON_LOADED before calling it. (or not) If you don't need the module to be loadable on demand you can also destroy the function to free up that memory.

Yeah, I thought about that approach, but I didn't really like the way it works.

Hm... maybe I should re-design overall structure

[Lombra]

The only other way I can think of is having the modules as separate addons.

[Layback_]

Originally Posted by Lombra The only other way I can think of is having the modules as separate addons.

Like the OP of this thread suggests?

[Lombra]

Yep.

tooshort

[Layback_]

Originally Posted by Lombra Yep. tooshort

If you were to make such addon, which method would you prefer to use?

1. Putting if statement at the top of each lua files

2. creating separate addon for each modules

3. none of the above, but different approach

[Fizzlemizz]

Define what you are trying to do.

If you are creating an overarching environment you intend to pretty much stay intact with just various options then putting everything under a single folder would seem sensible.

If you intend to create a bunch of independent modules that can be used alone or as part of a UI with maybe some changing of SavedVariable settings then seperate folders/addons would seem sensible here.

A combination of these two approaches may also be viable, depending on what are are trying to achieve.

[Layback_]

Originally Posted by Fizzlemizz Define what you are trying to do. If you are creating an overarching environment you intend to pretty much stay intact with just various options then putting everything under a single folder would seem sensible. If you intend to create a bunch of independent modules that can be used alone or as part of a UI with maybe some changing of SavedVariable settings then seperate folders/addons would seem sensible here. A combination of these two approaches may also be viable, depending on what are are trying to achieve.

I guess it would be a combination of both.

For some UI features like Unitframe and Actionbar, they could go into a Single addon folder as they are core features of game play while some other modules like "AddonSkin" or "CurrencyTracker" could go into separate addon folders.

BUT, if possible I am also willing to enable/disable those core features like Unitframe and Actionbar, then switch back to blizzard default UIs, and that would be the main reason of why I started this thread !

[Lombra]

Originally Posted by Layback_ If you were to make such addon, which method would you prefer to use? 1. Putting if statement at the top of each lua files 2. creating separate addon for each modules 3. none of the above, but different approach

Well, depends on the nature of the addon and the modules, I think.

As I said in the other thread, as a user I generally prefer the least amount of folders possible, though you may not be concerned with that. Obviously, sometimes it makes sense to have "folder modules".

I would probably consider the size and significance of each module. The larger the module, the more appropriate to do it as a folder. If the module is very small relative to the addon though, I would reconsider whether I really need to disable it. Just hiding it might suffice.

I don't know what your addon is, but if actionbars and unit frames is something that can be disabled, at that point why not just disable the whole addon?

[Layback_]

Originally Posted by Lombra I don't know what your addon is, but if actionbars and unit frames is something that can be disabled, at that point why not just disable the whole addon?

Basically the addon will contain those core features like unitframe, actionbar, minimap and so on where unitframe would be a re-creation with oUF, actionbar with LibActionButton while the rest of them (such as minimap and container frame) are pretty much just re-skinning.
(Not sure of what I should actually call this kind of addon UI suite, maybe?)

It's like Is: UI by lightspark.

So, each of those features will be modularized and easily enabled/disabled (toggled) via interface options.

[jeruku]

There is always putting the module init in a function loaded at ADDON_LOADED and have these functions called and removed after first use.

Quick dirty example:

--Core
local addonName, addonTable = ...
addonTable.CreateModule = {}
addonTable.Module = {}
 
local frame = CreateFrame('frame')
 
frame:SetScript('OnEvent', function(self, ...)
    addonTable:LoadModules()
end
function addonTable:LoadModules()
    for x, v in pairs(addonTable.CreateModule) do
        v()
    end
    --addonTable.CreateModule = nil -- or just delete the dang module creation
end
frame:RegisterEvent('ADDON_LOADED')

--ModuleA
local addonName, addonTable = ...
function addonTable.Module.ModuleA:Load()
    -- saved variables should be loaded since this is called in the core after ADDON_LOADED
    if SVTest.db.global.moduleA then
        local ModuleA
        --load/create the module/frame/objects/stuff
        for x, v in pairs(addonTable.CreateModule) do
            v(ModuleA)
        end
        --feel free to do more
 
        addonTable.Module = ModuleA
    end
    --then delete it
     addonTable.CreateModule.ModuleA = nil
end

--ModuleA.another  it's in another file
local addonName, addonTable = ...
-- it should only reach this point if it's enabled
function addonTable.CreateModule.ModuleA.another:Load(ModuleA)
    -- load/create the module/frame/objects/stuff
end

[Layback_]

Originally Posted by jeruku There is always putting the module init in a function loaded at ADDON_LOADED and have these functions called and removed after first use.

So, in my case, where I use Ace3, it would be:

Core.lua

local _G = _G;
 
-- Declare addon ------------------------------------------------------------------
local Core = LibStub("AceAddon-3.0"):NewAddon("MyUI_Core", "AceEvent-3.0");
_G.MyUI_Core = Core;
 
-- Defaults db --------------------------------------------------------------------
local defaults = {
    global = {
        modules = {
            Unitframe = true,
            Actionbar = true,
        },
    },
}
 
-- AddOn initialization method ----------------------------------------------------
-- According to Ace3, :OnInitialize() is called after all addons are loaded -------
-- Replaces ADDON_LOADED event from jeruku's example ------------------------------
function Core:OnInitialize()
    self.db = LibStub("AceDB-3.0"):New("MyUIDB", defaults, true);
 
    for k, v in pairs(self.db.global.modules) do
        if not v then
            local module = self:GetModule(k);
 
            module:Disable();
            module = nil;
        end
    end
end

Unitframe.lua

-- Declare module -----------------------------------------------------------------
local Unitframe = MyUI_Core:NewModule("Unitframe");
 
-- Module codes continued...

But, doesn't this mean it would, at least, go through the lua files once no matter whether the module is enabled/disabled?

[jeruku]

Something like that(?). I do not use Ace so I am trying to wrap my head around it and explain my method.

Basically you wrap your entire module creation code inside a function in a Lua file, this function can be called after saved variables are loaded, thus you can check the saved variable if it is enabled, if it is not you do not call the module creation function, and therefore the function(module) never gets called and goes to garbage collection.

If you want a horribly disgusting abomination of an example you can check out JamPlates Accessories.

I'd like to point out, I'm doing this after waking.

[Layback_]

Originally Posted by jeruku Something like that(?). I do not use Ace so I am trying to wrap my head around it and explain my method. Basically you wrap your entire module creation code inside a function in a Lua file, this function can be called after saved variables are loaded, thus you can check the saved variable if it is enabled, if it is not you do not call the module creation function, and therefore the function(module) never gets called and goes to garbage collection. If you want a horribly disgusting abomination of an example you can check out JamPlates Accessories. I'd like to point out, I'm doing this after waking.

So that's same as Lombra's method here.

mmmmmmmmmmmmmmm...

But what if one module is created with several lua files?

Currently, my unitframe module is a combination of unitframe.lua (which I declare module with Ace3), api.lua, config.lua, core.lua, group.lua, player.lua and some element lua files.

[jeruku]

Yes.

And now I feel the fool. Suppose this should be clarified but there are two ways of going about it this way.

One makes it toggled, though for certain features toggles can be dangerous; such as unitframes.
The other involves a reload after enabling/disabling; safer for uniframes and actionbars.

In both options a function for creating a module/feature is used to declare/create the base feature, this function is called after ADDON_LOADED which allows the saved variables to be used. Other Lua files can be used using the shared addonTable(the scoped vararg passed to each Lua file) or globals, though not recommended, where their main function is called in that modules main/core creation function. This then creates that module in a chain reaction when/if the main/core function is called.
Now here is where they differ; in a toggle the function(s) would not be deleted but reserved to toggle on/off without reload, in the second option the function(s) are deleted after use either by nil or written off for garbage collection(a local function not used before EOF, end of file, is deleted) requiring a reload if the module is enabled/disabled.

Hope this helps.

I have updated my previous post to actually show what I am describing in the second option. Apologies for not converting it to Ace.

[myrroddin]

Layback, you mentioned you use Ace3 to create a core addon and its modules. After poking around with this, I got it to work with SmartRes2 and SmartRes2_Chat.

What I noticed about your example and test code is that you are putting your core addon into the global namespace, which is not necessary, or even desireable. Instead, pull a local reference in the first line of your module code.

Also, AceLocale-3.0 localization tables are extendable (not extensible, you cannot add or modify AceLocale's code). Again, have a look at what I did in both the core and module.

In hindsight, it was remarkably easy, although a lack of good examples was a challenge. But now there is an example

Hopefully this helps, and if you have questions, please ask!

[Layback_]

Originally Posted by jeruku Yes. And now I feel the fool. Suppose this should be clarified but there are two ways of going about it this way. One makes it toggled, though for certain features toggles can be dangerous; such as unitframes. The other involves a reload after enabling/disabling; safer for uniframes and actionbars. In both options a function for creating a module/feature is used to declare/create the base feature, this function is called after ADDON_LOADED which allows the saved variables to be used. Other Lua files can be used using the shared addonTable(the scoped vararg passed to each Lua file) or globals, though not recommended, where their main function is called in that modules main/core creation function. This then creates that module in a chain reaction when/if the main/core function is called. Now here is where they differ; in a toggle the function(s) would not be deleted but reserved to toggle on/off without reload, in the second option the function(s) are deleted after use either by nil or written off for garbage collection(a local function not used before EOF, end of file, is deleted) requiring a reload if the module is enabled/disabled. Hope this helps. I have updated my previous post to actually show what I am describing in the second option. Apologies for not converting it to Ace.

I really, really and really appreciate your detailed explanations, and you do not need to apologize for not converting it to Ace. It's not your responsibility to do so, but mine

As for unitframe and actionbar, modules that would go into same (core) folder, I would follow your second option as the memory management is definitely a part of my consideration.

Thanks again!

[Layback_]

Originally Posted by myrroddin Layback, you mentioned you use Ace3 to create a core addon and its modules. After poking around with this, I got it to work with SmartRes2 and SmartRes2_Chat. What I noticed about your example and test code is that you are putting your core addon into the global namespace, which is not necessary, or even desireable. Instead, pull a local reference in the first line of your module code. Also, AceLocale-3.0 localization tables are extendable (not extensible, you cannot add or modify AceLocale's code). Again, have a look at what I did in both the core and module. In hindsight, it was remarkably easy, although a lack of good examples was a challenge. But now there is an example Hopefully this helps, and if you have questions, please ask!

Yeap, I definitely got a question

On SmartRes2, you enable/disable addon and its modules via options panel (with GetModuleEnabled & SetModuleEnabled functions), but doesn't reload ui which means you keeping its functions (since there is not frame). But, what if there were bunch of frames and local functions & tables?

Wouldn't that be a waste of memory?

Here's my working example (prototype) that draws extra power bar on player's screen.


ExtraPower.lua

-- Declare addon ------------------------------------------------------------------
local ExtraPower = LibStub("AceAddon-3.0"):NewAddon("ExtraPower");
 
-- Defaults db --------------------------------------------------------------------
local defaults = {
    global = {
        power = {
            width = 250,
            height = 15,
            point = {"CENTER", UIParent, "CENTER", 0, -150},
        },
 
        classicon = {
 
        },
    }
}
 
-- AddOn OnInitialize method ------------------------------------------------------
function ExtraPower:OnInitialize()
    self.db = LibStub("AceDB-3.0"):New("ExtraPowerDB", defaults, true);
end

Power.lua

-- Get addon ----------------------------------------------------------------------
local ExtraPower = LibStub("AceAddon-3.0"):GetAddon("ExtraPower");
 
-- Declare module -----------------------------------------------------------------
local Power = ExtraPower:NewModule("Power");
 
-- Declare & define variables -----------------------------------------------------
local db;
 
local LSM = LibStub("LibSharedMedia-3.0");
local font = LSM:Fetch("font", "MeatEdition");
local statusbar = LSM:Fetch("statusbar", "fer28");
 
local InitBarAndText, UpdateBarAndText;
 
-- Create frame -------------------------------------------------------------------
-- This is here for its event functions -------------------------------------------
do
    local bar = CreateFrame("StatusBar", Power:GetName() .. "Bar", UIParent);
    bar:RegisterEvent("PLAYER_ENTERING_WORLD");
    bar:RegisterUnitEvent("UNIT_POWER_FREQUENT", "player", "vehicle");
 
    Power.bar = bar;
end
 
function InitBarAndText()
    local bar = Power.bar;
 
    bar:SetMinMaxValues(0, 100);
    bar:SetStatusBarTexture(statusbar);
    bar:SetSize(db.power.width, db.power.height);
    bar:SetPoint(unpack(db.power.point));
    bar:SetTemplate(true);
    bar:SetBackground();
 
    bar.playerClass = nil;
 
    local text = bar:CreateFontString("$parentText", "OVERLAY");
    text:SetFont(font, 12, "OUTLINE");
    text:SetAllPoints();
 
    bar.text = text;
end
 
function UpdateBarAndText()
    local bar = Power.bar;
 
    local _, playerClass = UnitClass("player");
 
    local unitPower, unitPowerMax = UnitPower("player"), UnitPowerMax("player");
    local unitPowerPerc = unitPower / unitPowerMax * 100;
 
    if not bar.playerClass or bar.playerClass ~= playerClass then
        local color = RAID_CLASS_COLORS[playerClass];
 
        bar:SetStatusBarColor(color.r, color.g, color.b);
        
        bar.background:SetVertexColor(color.r * 0.25, color.g * 0.25, color.b * 0.25);
 
        bar.text:SetTextColor(color.r, color.g, color.b);
 
        bar.playerClass = playerClass;
    end
 
    bar:SetValue(unitPowerPerc);
 
    bar.text:SetFormattedText("%d (%d%%)", unitPower, unitPowerPerc);
end
 
function Power:OnInitialize()
    db = ExtraPower.db.global;
 
    InitBarAndText();
end
 
function Power.bar:OnEvent(event, ...)
    if event == "PLAYER_ENTERING_WORLD" then
        self:PLAYER_ENTERING_WORLD();
    elseif event == "UNIT_POWER_FREQUENT" then
        self:UNIT_POWER_FREQUENT(...);
    end
end
 
function Power.bar:PLAYER_ENTERING_WORLD()
    UpdateBarAndText();
 
    self:UnregisterEvent("PLAYER_ENTERING_WORLD");
end
 
function Power.bar:UNIT_POWER_FREQUENT(...)
    UpdateBarAndText();
end
 
Power.bar:SetScript("OnEvent", Power.bar.OnEvent);

[Seerah]

https://www.tutorialspoint.com/lua/l...collection.htm

Set it to nil, and the garbage collector will automatically pick it up when it runs its next cycle.