Thread Tools Display Modes
02/22/15, 11:14 AM   #1
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 1,579
LibAddonMenu-2.0r17 is now available

This version ensures that LibAddonMenu-2.0 is working correctly with Update 6 and will also work with Update 5.

It also fixes an issue in how the loading of the library was handled.
Right now older versions that are no longer compatible with the current API cause it to throw errors or prevent the addon settings from working correctly.
This fix cannot help with existing cases where such errors occur, but will prevent them from happening in the future.
Because of this it is important that all addons update their copy of LAM to r17 as soon as possible.

You can download the latest version from here as usual.
Also check out the new LAM2 wiki on github.
  Reply With Quote
02/22/15, 02:35 PM   #2
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 5,014
Great to read, thanks to the guys contributing to this addon to keep it upt o date!

Am I able to update existing addons on the live server with this version of LAM 2.0 without having to enable "older addons"?
Or do I have to wait for the live servers to patch to new API version?
  Reply With Quote
02/22/15, 03:16 PM   #3
merlight
AddOn Author - Click to view addons
Join Date: Jul 2014
Posts: 671
Originally Posted by Baertram View Post
Great to read, thanks to the guys contributing to this addon to keep it upt o date!

Am I able to update existing addons on the live server with this version of LAM 2.0 without having to enable "older addons"?
Or do I have to wait for the live servers to patch to new API version?
When bundling a library you don't include its manifest, so it doesn't matter (as long as it doesn't call new APIs, which it doesn't). I'm not really sure, but I think if you would, it'd then show up in game as a separate addon once for every addon bundling it.
  Reply With Quote
02/22/15, 05:57 PM   #4
Garkin
 
Garkin's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 832
For the dropbox widget:

Lua Code:
  1. local countControl = parent
  2. local name = parent:GetName()
  3. if not name or #name == 0 then
  4.     countControl = LAMCreateControl
  5.     name = "LAM"
  6. end
  7. local comboboxCount = (countControl.comboboxCount or 0) + 1
  8. countControl.comboboxCount = comboboxCount
  9. control.combobox = wm:CreateControlFromVirtual(zo_strjoin(nil, name, "Combobox", comboboxCount), control, "ZO_ComboBox")
I do not fully understand this code. Why you just simply do not use panel name? All panels must have name. But you have to count with submenus, so:
Lua Code:
  1. local panel = parent.panel or parent

As I have written week ago in comments to LAM, simple and easy way is:
Lua Code:
  1. local panel = parent.panel or parent
  2. panel.comboboxCount = (panel.comboboxCount or 0) + 1
  3. control.combobox = wm:CreateControlFromVirtual(panel:GetName().."Combobox"..panel.comboboxCount, control, "ZO_ComboBox")
  Reply With Quote
02/23/15, 05:22 AM   #5
votan
 
votan's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2014
Posts: 578
Hi, Garkin.

It has something to do with creating those controls outside LAM settings panel.
I'm not 100% sure, but I think it was "No, Thank You" which was creating a control named "Combobox1". Which did not conflict, but it is not a wise name.
The name of the parent and not it's panel is used as a prefix and therefore source of potential duplicate name generation. If there is no prefix, a global prefix with a global counter is used. Just to be sure.
If everything is as it should be, a counter per parent control is used as you suggested.

Originally Posted by Garkin View Post
As I have written week ago in comments to LAM, simple and easy way is:
Lua Code:
  1. local panel = parent.panel or parent
  2. panel.comboboxCount = (panel.comboboxCount or 0) + 1
  3. control.combobox = wm:CreateControlFromVirtual(panel:GetName().."Combobox"..panel.comboboxCount, control, "ZO_ComboBox")
  Reply With Quote
02/23/15, 05:39 AM   #6
Garkin
 
Garkin's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 832
Originally Posted by votan View Post
Hi, Garkin.

It has something to do with creating those controls outside LAM settings panel.
I'm not 100% sure, but I think it was "No, Thank You" which was creating a control named "Combobox1". Which did not conflict, but it is not a wise name.
The name of the parent and not it's panel is used as a prefix and therefore source of potential duplicate name generation. If there is no prefix, a global prefix with a global counter is used. Just to be sure.
If everything is as it should be, a counter per parent control is used as you suggested.
Code:
NoThankYou.lua:
local panel = LAM:RegisterAddonPanel("NOTY_Panel", panelData)

LibAddonMenu-2.0.lua:
function lam:RegisterAddonPanel(addonID, panelData)
    local panel = lamcc.panel(nil, panelData, addonID)    --addonID==global name of panel

panel.lua:
function LAMCreateControl.panel(parent, panelData, controlName)
    local control = wm:CreateTopLevelWindow(controlName)
As you can see, panel must have global name (addonID). So, code which I have posted before will create combobox with name "NOTY_PanelCombobox1". Is anything wrong with this name?
  Reply With Quote

ESOUI » Developer Discussions » General Authoring Discussion » LibAddonMenu-2.0r17 is now available


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off