I've just begun the process to update my addon from Ace2 to Ace3 and I haven't been reading the forums, or looking at addon source for quite some time so I'm a bit out of the loop when it comes to all the changes.
Currently my addon (EveryQuest) works okay with Ace2, but it is quite ugly in terms of the source. I never really got good at Lua and would just trial and error everything until something worked. I'd rather not have to start completly over with an Ace3 version to trial and error everything.
Here's my situation:
My addon uses Quixote-1.0, there's a new LibStub version, LibQuixote-2.0 that uses CallbackHandler. Currently all the documentation for CallbackHandler is how to use it in a library not how to use the library in an addon that uses it.
In the start of my code, I have:
EveryQuest = LibStub("AceAddon-3.0"):NewAddon("EveryQuest", "AceConsole-3.0", "AceEvent-3.0")
local Quixote = LibStub("LibQuixote-2.0")
local L = LibStub("AceLocale-3.0"):GetLocale("EveryQuest")
The first of the arguments is the name of the callback that is being made available by Quixote, and the second is the name of the function to be called. Am I correct so far? Also, please explain the actual function that is being called, is it EveryQuest:Quest_Gained()? or just Quest_Gained(), would it be the first if I Mixin Quixote?
The second problem I have is I use DewdropLib for my zone selection menu. Though I saw somewhere that there's an AceConfig for dropdown menus. Could someone explain how I would go about creating a standalone dropdown menu? This menu is tied to a [FONT=Courier New]UIDropDownMenuTemplate[/FONT] frame. I also use Dewdrop for rightclicking a quest in the list to change it's status.
The third question is about profiles. By default in Ace2, it created profiles and you could access the current profile using [FONT=Courier New]self.db.profile[/FONT] and [FONT=Courier New]self.db.char[/FONT]. My addon absolutely needs to be able to access the old Ace2 DB files. EveryQuest stores the quest history per-character and the rest of the settings account wide.
In relation to profiles, when setting up the DB in Ace2 I setup defaults, 1 set of defaults for per-character, and another for profiles. How does this work in Ace3. I found an example that shows it like this: (The WelcomeHome Ace3 version)
function mod:OnModuleEnable()
Prat.RegisterChatEvent(self,"Prat_PreAddMessage")
end
function mod:OnModuleDisable()
Prat.UnregisterAllChatEvents(self)
end
function mod:Prat_PreAddMessage(event, ...)
-- event == "Prat_PreAddMessage" btw
end
function mod:OnModuleEnable()
Prat.RegisterChatEvent(self,"Prat_PreAddMessage")
end
function mod:OnModuleDisable()
Prat.UnregisterAllChatEvents(self)
end
function mod:Prat_PreAddMessage(event, ...)
-- event == "Prat_PreAddMessage" btw
end
So the name of the register function depends on the library you are using?
I've just begun the process to update my addon from Ace2 to Ace3 and I haven't been reading the forums, or looking at addon source for quite some time so I'm a bit out of the loop when it comes to all the changes.
My best advice to you is to read existing source code of Ace3 addons. Omen3 shouldn't be too horrible to read for example. :)
EveryQuest = LibStub("AceAddon-3.0"):NewAddon("EveryQuest", "AceConsole-3.0", "AceEvent-3.0")
local Quixote = LibStub("LibQuixote-2.0")
local L = LibStub("AceLocale-3.0"):GetLocale("EveryQuest")
The first of the arguments is the name of the callback that is being made available by Quixote, and the second is the name of the function to be called. Am I correct so far? Also, please explain the actual function that is being called, is it EveryQuest:Quest_Gained()? or just Quest_Gained(), would it be the first if I Mixin Quixote?
EveryQuest:Quest_Gained() gets called if you mixed it in. If you had registered it as
Quixote:RegisterCallback("Quest_Gained", Quest_Gained)
without the quotations, then Quest_Gained() would be called instead, assuming Quest_Gained is a function. You can see GatherMate using callbacks by using AceEvent-3.0 (which is a wrapper around CBH)
The second problem I have is I use DewdropLib for my zone selection menu. Though I saw somewhere that there's an AceConfig for dropdown menus. Could someone explain how I would go about creating a standalone dropdown menu? This menu is tied to a [FONT=Courier New]UIDropDownMenuTemplate[/FONT] frame. I also use Dewdrop for rightclicking a quest in the list to change it's status.
There is a simple dropdown menu in Omen3 (when right clicking the title bar). Search for "Omen_TitleDropDownMenu" in the file.
You can also look at Gathermate, HandyNotes for examples of more simple dropdown menus. Note that in these examples I've listed, [FONT=Courier New]UIDropDownMenuTemplate[/FONT] is NOT used at all. Its only used if you want the nice horizontal long select box dropdown display with a nice arrow down button.
The third question is about profiles. By default in Ace2, it created profiles and you could access the current profile using [FONT=Courier New]self.db.profile[/FONT] and [FONT=Courier New]self.db.char[/FONT]. My addon absolutely needs to be able to access the old Ace2 DB files. EveryQuest stores the quest history per-character and the rest of the settings account wide.
You're in trouble. AceDB-3.0 does not read AceDB-2.0 data. You should preferably use a different savedvariable in your addon for your 3.0 version of the addon, but also load the 2.0 savedvariable data (its just a table), and write a custom function to import the data from your old 2.0 SV (you'll have to figure out how to read the data (the SV data also does not save values that are equal to the defaults) to the 3.0 SV. Once conversion is successful, you can then nil out or empty the old Savedvariable. Your ## SavedVariables field in the TOC can certainly specify more than one variable.
In relation to profiles, when setting up the DB in Ace2 I setup defaults, 1 set of defaults for per-character, and another for profiles. How does this work in Ace3. I found an example that shows it like this: (The WelcomeHome Ace3 version)
You're in trouble. AceDB-3.0 does not read AceDB-2.0 data. You should preferably use a different savedvariable in your addon for your 3.0 version of the addon, but also load the 2.0 savedvariable data (its just a table), and write a custom function to import the data from your old 2.0 SV (you'll have to figure out how to read the data (the SV data also does not save values that are equal to the defaults) to the 3.0 SV. Once conversion is successful, you can then nil out or empty the old Savedvariable. Your ## SavedVariables field in the TOC can certainly specify more than one variable.
So for me to read the Ace2 version's data, I have to change
## SavedVariables: EveryQuestDB
## SavedVariablesPerCharacter: EveryQuestDBPC
to
## SavedVariables: EveryQuestDB, EQ2DB
## SavedVariablesPerCharacter: EveryQuestDBPC, EQ2DBPC
Setup AceDB-3.0 to use EQ2DB and EQ2DBPC, then read EveryQuestDB and EveryQuestDBPC after VARIABLES_LOADED event has fired, then migrate it all to the AceDB-3.0?
Just use one Variable. IF you need something per char, just use the db.char table..
And put your DB decleration for AceDB-3 in the addon's OnInit() function.
Just use one Variable. IF you need something per char, just use the db.char table..
And put your DB decleration for AceDB-3 in the addon's OnInit() function.
Everything I save is per-character since it's quest history, only applies to 1 character. So if I use db.char that will only load that character's data? Since the db.char.history table gets very large once people start doing quests. Upwards of 50 additional tables, inside those a table for every quest the player has seen.
Plus what Xinhuan was saying is that AceDB-3.0 doesn't read AceDB-2.0 variables. So that I'd need to create a new AceDB-3.0 variable and read the original EveryQuestDB afterward not using AceDB-3.0
So for me to read the Ace2 version's data, I have to change
## SavedVariables: EveryQuestDB
## SavedVariablesPerCharacter: EveryQuestDBPC
to
## SavedVariables: EveryQuestDB, EQ2DB
## SavedVariablesPerCharacter: EveryQuestDBPC, EQ2DBPC
Setup AceDB-3.0 to use EQ2DB and EQ2DBPC, then read EveryQuestDB and EveryQuestDBPC after VARIABLES_LOADED event has fired, then migrate it all to the AceDB-3.0?
Yes, that is correct. After the migration, you can delete all the data in EveryQuestDB and EveryQuestDBPC so that the file just saves nothing in those variables. You'll still be loading/saving both variables, but you'll only be using one of them. You'll need to add checks or another flag as to whether migration has already taken place, such as EveryQuestDBPC.migrated = true.
Everything I save is per-character since it's quest history, only applies to 1 character. So if I use db.char that will only load that character's data? Since the db.char.history table gets very large once people start doing quests. Upwards of 50 additional tables, inside those a table for every quest the player has seen.
Orionshock is incorrect. Data stored in db.char is loaded across all characters if you registered the db as a global savedvariable.
Only data registered with AceDB-3.0 using a character specific SV is char specific. You will want to
## SavedVariables: EveryQuestDB, EQ2DB
## SavedVariablesPerCharacter: EveryQuestDBPC, EQ2DBPC
function EveryQuest2:OnInitialize()
self.db = LibStub("AceDB-3.0"):New("EQ2DB", defaults)
self.dbpc = LibStub("AceDB-3.0"):New("EQ2DBPC", defaultspc)
-- Check contents of EveryQuestDB and EveryQuestDBPC and migrate
-- You should not delete any data in EveryQuestDB/EveryQuestDBPC
-- until you are absolutely sure the migration is successful.
end
For 2 (or more) level menus, one of your menu items on the 1st level would have
info.text = "my sub menu"
info.hasArrow = 1
info.value = "some id string"
UIDropDownMenu_AddButton(info, level)
Now remember the function has a argument passed in called "level"
if (level == 1) then -- this is a 1st level menu
-- blah blah
elseif (level == 2) then -- this is a 2nd level menu
if UIDROPDOWNMENU_MENU_VALUE == "some id string" then
info.blah = blah
info.blah = blah
UIDropDownMenu_AddButton(info, level)
elseif UIDROPDOWNMENU_MENU_VALUE == "some other id string" then
info.blah = blah
info.blah = blah
UIDropDownMenu_AddButton(info, level)
end
end
Edit:
Note that you can actually assign anything to info.value, which gets assigned to the global variable UIDROPDOWNMENU_MENU_VALUE so you can identify what submenu to display, but strings are preferred.
So all you now need is a nice set of loops to do this for your quest-categories.
I've just begun the process to update my addon from Ace2 to Ace3 and I haven't been reading the forums, or looking at addon source for quite some time so I'm a bit out of the loop when it comes to all the changes.
Currently my addon (EveryQuest) works okay with Ace2, but it is quite ugly in terms of the source. I never really got good at Lua and would just trial and error everything until something worked. I'd rather not have to start completly over with an Ace3 version to trial and error everything.
Here's my situation:
My addon uses Quixote-1.0, there's a new LibStub version, LibQuixote-2.0 that uses CallbackHandler. Currently all the documentation for CallbackHandler is how to use it in a library not how to use the library in an addon that uses it.
In the start of my code, I have: I've seen something along the lines of The first of the arguments is the name of the callback that is being made available by Quixote, and the second is the name of the function to be called. Am I correct so far? Also, please explain the actual function that is being called, is it EveryQuest:Quest_Gained()? or just Quest_Gained(), would it be the first if I Mixin Quixote?
The second problem I have is I use DewdropLib for my zone selection menu. Though I saw somewhere that there's an AceConfig for dropdown menus. Could someone explain how I would go about creating a standalone dropdown menu? This menu is tied to a [FONT=Courier New]UIDropDownMenuTemplate[/FONT] frame. I also use Dewdrop for rightclicking a quest in the list to change it's status.
The third question is about profiles. By default in Ace2, it created profiles and you could access the current profile using [FONT=Courier New]self.db.profile[/FONT] and [FONT=Courier New]self.db.char[/FONT]. My addon absolutely needs to be able to access the old Ace2 DB files. EveryQuest stores the quest history per-character and the rest of the settings account wide.
In relation to profiles, when setting up the DB in Ace2 I setup defaults, 1 set of defaults for per-character, and another for profiles. How does this work in Ace3. I found an example that shows it like this: (The WelcomeHome Ace3 version) But in the WelcomeHome page, it doesn't actually show the table called defaults.
Thank you,
kandarz
So the name of the register function depends on the library you are using?
My best advice to you is to read existing source code of Ace3 addons. Omen3 shouldn't be too horrible to read for example. :)
There are lots of other Ace3 addons.
EveryQuest:Quest_Gained() gets called if you mixed it in. If you had registered it as
Quixote:RegisterCallback("Quest_Gained", Quest_Gained)
without the quotations, then Quest_Gained() would be called instead, assuming Quest_Gained is a function. You can see GatherMate using callbacks by using AceEvent-3.0 (which is a wrapper around CBH)
GatherMate:SendMessage("GatherMateConfigChanged")
Display:RegisterMessage("GatherMateConfigChanged","ConfigChanged")
There is a simple dropdown menu in Omen3 (when right clicking the title bar). Search for "Omen_TitleDropDownMenu" in the file.
You can also look at Gathermate, HandyNotes for examples of more simple dropdown menus. Note that in these examples I've listed, [FONT=Courier New]UIDropDownMenuTemplate[/FONT] is NOT used at all. Its only used if you want the nice horizontal long select box dropdown display with a nice arrow down button.
You're in trouble. AceDB-3.0 does not read AceDB-2.0 data. You should preferably use a different savedvariable in your addon for your 3.0 version of the addon, but also load the 2.0 savedvariable data (its just a table), and write a custom function to import the data from your old 2.0 SV (you'll have to figure out how to read the data (the SV data also does not save values that are equal to the defaults) to the 3.0 SV. Once conversion is successful, you can then nil out or empty the old Savedvariable. Your ## SavedVariables field in the TOC can certainly specify more than one variable.
Alternatively you will need to use Ace2 itself.
Sylvanaar's answered this one.
So for me to read the Ace2 version's data, I have to change
## SavedVariables: EveryQuestDB
## SavedVariablesPerCharacter: EveryQuestDBPC
to
## SavedVariables: EveryQuestDB, EQ2DB
## SavedVariablesPerCharacter: EveryQuestDBPC, EQ2DBPC
Setup AceDB-3.0 to use EQ2DB and EQ2DBPC, then read EveryQuestDB and EveryQuestDBPC after VARIABLES_LOADED event has fired, then migrate it all to the AceDB-3.0?
##Saved Variables: EveryQuestDB
Just use one Variable. IF you need something per char, just use the db.char table..
And put your DB decleration for AceDB-3 in the addon's OnInit() function.
Everything I save is per-character since it's quest history, only applies to 1 character. So if I use db.char that will only load that character's data? Since the db.char.history table gets very large once people start doing quests. Upwards of 50 additional tables, inside those a table for every quest the player has seen.
Plus what Xinhuan was saying is that AceDB-3.0 doesn't read AceDB-2.0 variables. So that I'd need to create a new AceDB-3.0 variable and read the original EveryQuestDB afterward not using AceDB-3.0
Yes, that is correct. After the migration, you can delete all the data in EveryQuestDB and EveryQuestDBPC so that the file just saves nothing in those variables. You'll still be loading/saving both variables, but you'll only be using one of them. You'll need to add checks or another flag as to whether migration has already taken place, such as EveryQuestDBPC.migrated = true.
Orionshock is incorrect. Data stored in db.char is loaded across all characters if you registered the db as a global savedvariable.
Only data registered with AceDB-3.0 using a character specific SV is char specific. You will want to
Now remember the function has a argument passed in called "level"
Edit:
Note that you can actually assign anything to info.value, which gets assigned to the global variable UIDROPDOWNMENU_MENU_VALUE so you can identify what submenu to display, but strings are preferred.
So all you now need is a nice set of loops to do this for your quest-categories.
In case you haven't already figured this out, don't do that or you will probably break every addon that uses Quixote and Quixote itself.
Would be the correct syntax.