I'm sure I should be able to find this myself, but I cant seem to, so sorry if it's an easy question.
I'm looking for a way to set checkbox' as arrays for easier working out later. The reason for this is that I have created a new version of my addon and overall it has over 100 checkboxes, and individually checking which one it is just looks like a massive mess and I really dont like messy code. I'm sure it's got to be the wrong way to do it and I'll explain exactly what I'm trying to do though in case there's an even simpler way of doing it.
In this part of the code I'm attempting to check for each spell I'm tracking, what channel the user wants the output to, and and a 5th option which varies slightly based on whether it's a buff or a ressurection, which is handled elsewhere in the code but needs to be saved none the less here.
My XML file for this part looks like this as psuedo-code:
DK frame of my addon
In the Hysteria Frame
Checkbox for "Whisper"
Checkbox for "Party"
Checkbox for "Raid"
Checkbox for "Situational"
Checkbox for "Warning Self"
Close Hysteria Frame
In the Raise Ally Frame
Checkbox for "Whisper"
Checkbox for "Party"
Checkbox for "Raid"
Checkbox for "Situational"
Checkbox for "Warning Self"
Close Raise Ally Frame
Close DK frame of my addon
-------------------------------
Then in the LUA file, this is the exact code for CheckButton_OnClick:
if ( this:GetName() == "DK_Whisper_1" ) then
if DK_Whisper_1:GetChecked() then
CheckTable[1] = "WHISPER"
CheckButtonsUpdate("DK");
else
CheckTable[1] = "False"
end
end
if ( this:GetName() == "DK_Whisper_2" ) then
if DK_Whisper_2:GetChecked() then
CheckTable[1] = "PARTY"
CheckButtonsUpdate("DK");
else
CheckTable[1] = "False"
end
end
if ( this:GetName() == "DK_Whisper_3" ) then
if DK_Whisper_3:GetChecked() then
CheckTable[1] = "RAID"
CheckButtonsUpdate("DK");
else
CheckTable[1] = "False"
end
end
if ( this:GetName() == "DK_Whisper_4" ) then
if DK_Whisper_4:GetChecked() then
CheckTable[1] = "ALL"
CheckButtonsUpdate("DK");
else
CheckTable[1] = "False"
end
end
if ( this:GetName() == "DK_Whisper_5" ) then
if DK_Whisper_5:GetChecked() then
SelfReportTable[1] = "True"
else
SelfReportTable[1] = "False"
end
end
if ( this:GetName() == "DK2_Whisper_1" ) then
if DK2_Whisper_1:GetChecked() then
CheckTable[2] = "WHISPER"
CheckButtonsUpdate("DK");
else
CheckTable[2] = "False"
end
end
if ( this:GetName() == "DK2_Whisper_2" ) then
if DK2_Whisper_2:GetChecked() then
CheckTable[2] = "PARTY"
CheckButtonsUpdate("DK");
else
CheckTable[2] = "False"
end
end
if ( this:GetName() == "DK2_Whisper_3" ) then
if DK2_Whisper_3:GetChecked() then
CheckTable[2] = "RAID"
CheckButtonsUpdate("DK");
else
CheckTable[2] = "False"
end
end
if ( this:GetName() == "DK2_Whisper_4" ) then
if DK2_Whisper_4:GetChecked() then
CheckTable[2] = "ALL"
CheckButtonsUpdate("DK");
else
CheckTable[2] = "False"
end
end
if ( this:GetName() == "DK2_Whisper_5" ) then
if DK2_Whisper_5:GetChecked() then
SelfReportTable[2] = "True"
else
SelfReportTable[2] = "False"
end
end
-------------------------------
And in short, it's very very messy. So it does all work, but I'm wondering if anyone could tell me a better way of doing it in terms of best practice coding. My coding background is mostly in Basic/Visual Basic so I'm instinctively thinking I need an array of checkboxes and to load each one in as I load the addon, but I cant seem to find any way of doing it.
There is quite a lot to say about this, but I'd instead like to ask: have you considered just using Ace3? It really makes creating configuration UIs so much easier. Not only that, but the user experience is very consistent between add-ons that use Ace3. Just a thought before we dive into your current methodology.
To be honest, I looked in to what Ace3 was shortly after I started trying to make an addon and it looked like a load of extra things to try to learn, when my goal was to make a simple and easy addon so I decided not to look further in to it. Additionally, having done more reading after your post, I still dont understand how I could use Ace3 to my benefit at the moment or how to efficiently learn how to use it.
I'm not opposed to putting the time and effort in to learn how to apply it if it really is the best option for the addon and the end user however.
AceConfig-3.0 is the component that lets you take a table in a standard format, and automatically make a highly functional UI out of it. This UI can be placed inside the Blizzard Interface Options dialog right alongside other add-ons. You get all kinds of features including tabs, hierarchical lists, drop downs, multiselect checkboxes (similar to what you've done), etc. Everything can optionally be resized and scrolled, and it reflows nicely and behaves well. You get all of this for minimal effort.
Check out the documentation below. Then find a few simple add-ons that make use of Ace3 for their configuration UI and learn by example. It'll be a big change from what you're currently doing, but I promise you that once you make the leap, a whole new world of possibilities will open up. Ultimately, the configuration UI should not be the primary work effort in your add-on -- the program logic should be. Ace3 solves the UI problem in a very elegant and extremely well-supported, consistent fashion.
Note that for the best outcome, you should also consider refactoring to use AceDB-3.0 and AceDBOptions-3.0, thereby giving your users the standardized Profiles experience.
I can provide the code to feed your options into the Interface Options dialog if you need it, but again, virtually any modern Ace3 add-on does this, so you can learn by example.
short of using ace to handle things, you can certainly move to a table-based approach and instead of hand-coding your buttons and frames, have your lua script build them based on your table data. if you find you're typing in the same bit of code 3 or 4 times, figure there's a better approach that uses a loop and a lookup table.
i would consider stuffing data into your buttons that control their behavior, then use a single, simple click-script. each button needs to know what value it needs to set in your code and what group it belongs to so it can uncheck its peers.
your clickscript could be:
local function CheckBox_OnClick(checkBox)
if checkBox:GetChecked() then
checkTable[checkBox.ability] = checkBox.announceType
CheckButtonsUpdate(checkBox.class)
else
checkTable[checkBox.checkTableIndex] = "False"
end
end
then it's just a matter of looping over the classes and each set of abilities to generate each button group (also a loop of announce types).
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I'm sure I should be able to find this myself, but I cant seem to, so sorry if it's an easy question.
I'm looking for a way to set checkbox' as arrays for easier working out later. The reason for this is that I have created a new version of my addon and overall it has over 100 checkboxes, and individually checking which one it is just looks like a massive mess and I really dont like messy code. I'm sure it's got to be the wrong way to do it and I'll explain exactly what I'm trying to do though in case there's an even simpler way of doing it.
In this part of the code I'm attempting to check for each spell I'm tracking, what channel the user wants the output to, and and a 5th option which varies slightly based on whether it's a buff or a ressurection, which is handled elsewhere in the code but needs to be saved none the less here.
My XML file for this part looks like this as psuedo-code:
DK frame of my addon
Close DK frame of my addon
-------------------------------
Then in the LUA file, this is the exact code for CheckButton_OnClick:
-------------------------------
And in short, it's very very messy. So it does all work, but I'm wondering if anyone could tell me a better way of doing it in terms of best practice coding. My coding background is mostly in Basic/Visual Basic so I'm instinctively thinking I need an array of checkboxes and to load each one in as I load the addon, but I cant seem to find any way of doing it.
Thanks in advance for any help.
I'm not opposed to putting the time and effort in to learn how to apply it if it really is the best option for the addon and the end user however.
Edit: I'll also add the menu I'm working on here so it's clear exactly what I'm aiming at.
Edit2: I'll link to it instead. http://i275.photobucket.com/albums/jj305/Irbeth/NewLayout.jpg
Check out the documentation below. Then find a few simple add-ons that make use of Ace3 for their configuration UI and learn by example. It'll be a big change from what you're currently doing, but I promise you that once you make the leap, a whole new world of possibilities will open up. Ultimately, the configuration UI should not be the primary work effort in your add-on -- the program logic should be. Ace3 solves the UI problem in a very elegant and extremely well-supported, consistent fashion.
Note that for the best outcome, you should also consider refactoring to use AceDB-3.0 and AceDBOptions-3.0, thereby giving your users the standardized Profiles experience.
Getting started with Ace3: http://www.wowace.com/addons/ace3/pages/getting-started/
The options table format: http://www.wowace.com/addons/ace3/pages/ace-config-3-0-options-tables/
I can provide the code to feed your options into the Interface Options dialog if you need it, but again, virtually any modern Ace3 add-on does this, so you can learn by example.
Thanks again. :)
Edit: Though if anyone wants to post any tips to help or things to consider with regards converting it over, I'd still appreciate them.
i would consider stuffing data into your buttons that control their behavior, then use a single, simple click-script. each button needs to know what value it needs to set in your code and what group it belongs to so it can uncheck its peers.
your clickscript could be:
then it's just a matter of looping over the classes and each set of abilities to generate each button group (also a loop of announce types).