AceDB Resetting
Started having an issue earlier where AceDB wasn't keeping my settings, however my SavedVariables are saving right. Was wondering if anybody has encountered this before. I'm using AceConfig with a dropdown to choose between "BOTTOM" and "TOP". When I do the call to Refresh() it changes correctly, but after a UIReload it goes back to the BOTTOM.
TOC Information: Lua Code:
Here's how I'm initiating the DB (in AddOn:OnInitialization): Lua Code:
Here's the defaults: Lua Code:
SavedVariables: Lua Code:
Here's how I'm setting it in my AceConfig options: Lua Code:
Here's how I'm using it (in Addon:Refresh): Lua Code:
EDIT: For reference, full source: https://github.com/MilleXIV/XIV_Databar/tree/ace-rework and commit it broke after: https://github.com/MilleXIV/XIV_Data...214a286bc1840b. |
Call AddOn:Refresh() in your AddOn:OnInitialize() section, after setting up your SVs.
|
Quote:
Full source is found at https://github.com/MilleXIV/XIV_Databar/tree/ace-rework if it would help anybody. |
Okay, before I go deeper into your initial problem, here's some feedback:
|
Quote:
|
OnInitialize() is called once, during AddOn startup. Think of it as a very fancy wrapper for ADDON_LOADED, because, among other things, you do not need to weed out all the other AddOns to find yours.
OnEnable() and OnDisable() are called whenever your AddOn is enabled or disabled. In your defaults table, if you have a variable that flags the AddOn as enabled (call it enabled, or enabledAddOn, or Tony) "true", you can then, in OnInit, after setting up the SVs, call Code:
self:SetEnabledState(self.db.profile.enabled) Code:
enabled = { |
About your profiles, here's another tip. You don't even need to have the word "Profiles" at all. Again, Ace3 will do stuff automatically for you. The second line is optional. I have it because I want my Profiles tab to be the last tab, and since I have 5 tabs in my options table, setting the order to 90 ensures that.
Code:
options.args.profiles = LibStub("AceDBOptions-3.0"):GetOptionsTable(self.db) |
Here is some more stuff.
Code:
local L = LibStub("AceLocale-3.0"):GetLocale(AddOnName, true) -- true, not false |
|
Quote:
|
Okay, lots of feedback there.
|
You can also look at Blizzard's globalstrings.lua to see if there is any words or phrases they have already translated. For example, do a search for "general options" and look what you find.
Replace all instances of L["General"] with COMPACT_UNIT_FRAME_PROFILE_SUBTYPE_ALL as one example. Also, in your localization file for enUS.lua, delete if not L then return; end –– afterall, this is your default localization. If someone playing on deDE loaded your AddOn, absolutely zero text would be displayed except of any globalstrings. The beginning of enUS.lua should look like this. Code:
local AddOnName, Engine = ...; Code:
local L = LibStub("AceLocale-3.0"):GetLocale(AddOnName, false) |
Quote:
4. Hey, if it works, it works. I merely saw something that struck me as odd, and most of the time, odd = doesn't work. I've been wrong about stuff like this many, many times before. :p |
Will have to look into the globalstrings.lua for anything I need. Did not know about that.
Quote:
4. Yeah, the way I have it those groups show up as the content of my addon's node in the options looking similar to an HTML fieldset. I'd post a screenshot, but at work currently. Also, just had a flash of memory. This is the commit after which things stopped working: https://github.com/MilleXIV/XIV_Data...214a286bc1840b. My only guess with this is the inclusion of AceEvent? |
Quote:
1. Forcing the Blizzard_TradeSkillUI to load isn't optimal. All the API functions to get data about your character's trade skills and recipes should be available and fully functional without loading the UI. If your addon is modifying the UI (I didn't actually check) then it would be better to delay that part of your addon until the UI is loaded naturally. Listen for ADDON_LOADED where arg1 is "Blizzard_TradeSkillUI". 2. While it doesn't affect functionality, organizing your code a little better will help you (and anyone else reading it) keep track of what's going on in the future. For example, here you're randomly mixing RegisterEvent and SetScript lines. It would be easier to tell, at a glance, what all is happening there if you put all the RegisterEvent lines together, and all the SetScript lines together. 3. What on earth is going on here? Rather than having one (named) function that just creates and returns another (anonymous) function that's always the same (eg. it doesn't change depending on what's passed to the wrapper function, or on any other variables or conditions), just name that inner function and refer to it, rather than wrapping it and calling the wrapper to get the reference. Actually, since it looks like you only call each wrapper once to get the inner function to set it as an OnClick hander, you should just use the inner function (anonymously) directly in the SetScript call: Code:
self.frames.chat:SetScript('OnClick', function(self, button, down) As for the original problem, do you have an error display installed? While the built-in error display has gotten a little better over the years, it's still sadly lacking in some essential features, like the ability to show you errors that happen during the initial loading process (which is where many of your errors will occur during development). |
1. My issue with that was that my calls to some Tradeskill functions were doing nothing after the addon was loaded. Though that might just be how it was called. I haven't even tested if that fixed it, so it might not even be necessary. Will probably work better once I change it over to using Modules (I'm adapting/rewriting somebody else's old code, working on Micromenu first).
2. Yeah, could probably separate those. I was organizing more by thing than by what I'm doing. Shouldn't be much of a difference. 3. There are a few bits that will be wrapping the default to add some functionality for the OnEnter, so that's why I did it for that one. For the others I was wrapping the OnClick handlers in another function due to disliking having too many anonymous functions in-line. Probably should move it to variables instead of a function call though. 4. That's what I get for working on two different computers that seem to have different settings. That's easily fixable later. Is there a community suggested standard or is it just personal preference? (i.e. I know the PHP community standard is 4 spaces). I do have !BugGrabber and BugSack installed. I was getting no errors from my code, haven't checked since last night. |
ie, #4...
It's just personal preference, but be consistent. It will help you. I prefer tabs, but if I *have* to use spaces (here on the forums or whatever) I prefer 5 to 4. |
Quote:
|
So I've been running at this thing with the following script in WoWLua:
Lua Code:
Then stripped my addon down to as basic as I could. My OnInit only does AceDB:New, LSM:Register, self.frames = {}, sets up an options table (statically), then registers the options frame, and a slash command. My OnEnable has been set to just return. If I run that after loading into the game it's completely missing self.db.profile. After I load up my config it fills in self.db.profile with my defaults. The full OnInit/OnEnable/ToggleConfig: Lua Code:
|
Try stripping it down even more. Does this work?
Lua Code:
Also, if you're going to do this: lua Code:
... you also need to register for the callbacks AceDB fires when the profile is switched or reset, and update your "P" upvalue when those things happen. Otherwise, you'll still be referring to the old profile even though the user has chosen a different one. Finally, this makes my brain hurt: lua Code:
This pattern is awful. If you want XIVBar, L, and P to be accessible in all files, just do this: lua Code:
Generally speaking you don't need to explicitly create a global for your AceAddon addons. If you want to look it up in another file, or if another addon wants to access it, they can do LibStub("AceAddon-3.0"):GetAddon("XIVBar"). "P" shouldn't even be given a default value if you're just going to use it as a pointer to the current profile, and it definitely shouldn't be stored on the shared addon object where (presumably) you're going to assign "local P = Engine[3]" or whatever in other files, because (as noted above) you need to update that pointer if the user picked another profile. Really, you should just not bother with a file-level upvalue for "self.db.profile". If you're calling it so many times in a given function that it's tedious to type/read, or in a function where speed is of the essence (eg. CLEU or OnUpdate), just use an upvalue local to the function: lua Code:
That saves you the trouble of registering for profile callbacks and updating higher-level upvalues. |
All times are GMT -6. The time now is 10:28 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI