Walking before I Run....
1 Attachment(s)
Ok so instead of trying to figure out a "complete" UI I think I'm going to step back and try to just handle one addon.
So (for now) BasicUI will be put on the back shelf. I will upload the current version I have and let people us it if the like. The single addon I will be trying to keep up is nData (WoWInterface and GitHub). Can someone take a look at the zip file below to see if I have everything working correctly. Thanks for everyone's help. Coke |
First and foremost: LibDataBroker. Why are you embedding it when your addon does not use it? Though, really, your coding life would be much simpler if you did use it, and simpler still if you just used one of the many many existing Broker bars out there, that not only have as few (CargoShip, NinjaPanel) or as many (Bazooka, DockingStation) features as you want (StatBlocks and ChocolateBar fall closer to the middle of the feature spectrum, I think) but also support any number of plugins instead of a fixed 9, support an infinitely larger variety of existing plugins, and have compatibility already built into thousands of other addons.
There are plenty of other areas of the UI you could be spending your time on that aren't 100% wheel reinvention, and most of those other areas would be more immediately rewarding, in that you would be spending more time customizing appearances and behaviors with results you could enjoy right away, instead of spending a lot of time on a largely invisible backend framework before actually doing anything interesting. However, if you really want to keep on reinventing the wheel with a data panel: There's no need to nil out OnInitialize, as AceAddon will only ever call it once. Don't forget to re-set your "db" upvalue in your Refresh function if you plan to support profiles: Code:
db = self.db.profile Code:
self:SetEnabledState(db.enable) You're embedding LibSharedMedia-3.0 and the very large AceGUI-3.0-SharedMediaWidgets but not using them. If you don't plan to use them, get rid of these libraries. On a related note, don't put unrelated libraries into the same folder. The LibStub folder should ONLY contain LibStub. Put LibBasicAdjust-1.0 and tekShiner in their own folders, or just in the top-level Libs folder. And, don't include additional copies of LibStub and CallbackHandler in other libraries, as you're doing with LibDataBroker, and do embed the deepest path you can, so for LibDataBroker, you should be embedding the inner LibDataBroker-1.1 folder that only includes the library's Lua file and a README, not the outer folder that also includes a TOC and other clutter. You should either (a) do the panel creation -- self:CreatePanel() -- from OnInitialize insead of OnEnable, or (b) remove the "enable" option, since CreatePanel is only designed to be called once, but if you let users toggle the addon in-game (which, honestly, seems pointless in a self-contained addon they can just disable at the addon screen, or uninstall, if they want to stop using) then OnEnable can be called over and over. Also, if you keep the "enable" option, then you should add an OnDisable method that hides all the panels and does anything else you need to do to "turn off" the addon. AceAddon/AceEvent will automatically unregister any events registered on your addon object, but you should manually unregister events registered on other frames (eg. you can't use RegisterUnitEvent on an AceAddon object because AceEvent doesn't support it, and your individual data plugins are not AceAddon objects anyway). Unconditionally showing your frame on PLAYER_ENTERING_WORLD when you intend for it to be hidden in vehicles and pet battles may yield unexpected results if the user reloads their UI while in a vehicle or pet battle. I'd suggest changing that block as follows: Code:
if event == "UNIT_ENTERING_VEHICLE" or event == "PET_BATTLE_OPENING_START" then Rather than storing your plugin order using strings, eg. "P3", and then using a giant if-else chain on each plugin as it's created, I'd suggest using a simple indexed table to store the order: Code:
-- Stat Locations Code:
self.plugins = {} Code:
function nData:PlacePlugin(plugin, i) Your options table would be easier to extend and maintain if you wrote it in the desired order, instead of grouping options by type. Putting all the separators first, for example, requires reading through the order properties of the entire options table to figure out where those separators will actually appear in-game. You also have a lot of duplicate orders, which would be much easier to spot if your table was better organized. Finally, you don't need to specify orders for every single option. Use low numbers to force important stuff like the enable toggle to the top, and negative numbers to force low-priority items like reset buttons to the bottom, and let AceGUI arrange the rest alphabetically in between. |
Thank You Phanx for all this tips, I know it like reinventing the wheel but I guess people like what they like. I have 3k downloads for nData sence I set it up. I know not a lot but there are people that use it.
This part of the new PlacePlugin throws a error: Code:
local area = math.ceil(i / 3) Error: Code:
2x nData\nData-5.4.7.lua:225: attempt to perform arithmetic on local "i" (a table value) So when I got the plugin it self it uses nData:PlacePlugin(db.bags, Text) how will this new way work? Coke Edit: All the other adjustments are working great. Thank You :) |
Quote:
Quote:
Quote:
Also, please stop doing this: Code:
## Title: |cffCC3333 n|rData If you want to display your addon's name with colors in-game (eg. the title on your config panel) go for it, but please do not include color codes in any strings that are used in alphabetized lists. |
You'll also need to change your options to accommodate this... though after looking at them, your current setup doesn't really work anyway, because it doesn't do anything to stop users from setting every single plugin to position 5, for example, which would result in all of them being shown on top of each other.
Hardcoding all of your plugins into your options table is not ideal, as it rather defeats the point of setting up the name/constructor table, and requires a lot of writing the same thing over and over. Here's a better way; also, I made some additional changes to the other stuff to make it easier to manage In your defaults: Code:
-- Stat Locations Code:
local classColor, currentFightDPS Code:
local function sortPlugins(a, b) Code:
self.plugins = {} Code:
sort(pluginOrder, sortPlugins) Code:
local statposition = { Code:
DataGroup = { Code:
local t = options.args.datatext.args.DataGroup.args |
Also I peeked at one of your modules (Professions.lua), and you're leaking globals again; I assume the others have the same issue. For example, near the top you're leaking "db", "hexa" and "hexb" as globals.
Also you're doing some things wrong again: Code:
nData:PlacePlugin(db.pro, Text) 2 - You should not be placing the plugin inside its constructor function anyway. Just delete this line entirely. Code:
Text:SetFormattedText(hexa.."Professions"..hexb) Code:
if v ~= nil then Code:
local plugin = CreateFrame('Button', nil, Datapanel) However, specifying a parent here is still pointless, because you're going to re-parent the plugin frame later anyway. :p Code:
self:SetAllPoints(Text) Code:
self:SetWidth(self:GetStringWidth()) |
2 Attachment(s)
Quote:
Quote:
I went threw and change everything you stated above but apperantly I got lost and something aint correct cause as you stated earlier I get the tooltip not the text ont he bar. Quote:
Below is the addon zipped up with your changes (I think). Coke |
All times are GMT -6. The time now is 03:43 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI