LibAddonMenu-2.0r17 is now available

[sirinsidiator]

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.

[Baertram]

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?

[merlight]

Originally Posted by Baertram 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.

[Garkin]

For the dropbox widget:

local countControl = parent
local name = parent:GetName()
if not name or #name == 0 then
    countControl = LAMCreateControl
    name = "LAM"
end
local comboboxCount = (countControl.comboboxCount or 0) + 1
countControl.comboboxCount = comboboxCount
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:

local panel = parent.panel or parent

As I have written week ago in comments to LAM, simple and easy way is:

local panel = parent.panel or parent
panel.comboboxCount = (panel.comboboxCount or 0) + 1
control.combobox = wm:CreateControlFromVirtual(panel:GetName().."Combobox"..panel.comboboxCount, control, "ZO_ComboBox")

[votan]

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 As I have written week ago in comments to LAM, simple and easy way is: local panel = parent.panel or parent panel.comboboxCount = (panel.comboboxCount or 0) + 1 control.combobox = wm:CreateControlFromVirtual(panel:GetName().."Combobox"..panel.comboboxCount, control, "ZO_ComboBox")

[Garkin]

Originally Posted by votan 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.

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?

[votan]

Originally Posted by Garkin So, code which I have posted before will create combobox with name "NOTY_PanelCombobox1". Is anything wrong with this name?

No, no, sorry, as I said, I can not remember. But I can remember, that this function was called with a nameless parent. I printed out the names for debugging.

Any particular reason why it is so important? Did we miss something?

[Garkin]

Originally Posted by votan No, no, sorry, as I said, I can not remember. But I can remember, that this function was called with a nameless parent. I printed out the names for debugging. Any particular reason why it is so important? Did we miss something?

No, there is no real issue. I'm just saying. It works both ways. It's just that I don't like controls named LAMCombobox1.
Players do not care about control names, so there is nothing wrong with the way how it is now.

I was just trying to explain that in your code is used:

local name = parent:GetName()

This can return nil instead of string because parent could be unnamed submenu. Thats why I've suggested using:

local panel = parent.panel or parent
local name = panel:GetName()

So you will always get correct control name.

[sirinsidiator]

You are forgetting about something.
You can not assume that parent has a panel property or a name as it can be called by anyone from outside LAM. I think votan's version of the code is the preferable way to do it.

See #5 in Differences between v1.0 and v2.0.

[merlight]

Isn't it funny how such a seemingly trivial task as giving a name to a control can get so complicated? I like the simplicity of Garkin's method. Yes it has a prerequisite, but one that is already there.

Note that every LAM control constructor (except panel, obviously) sets:

control.panel = parent.panel or parent

Read that line carefully - it means that `parent` has to either have a link to a panel, or be a panel.

Of course being a panel doesn't necessarily equal to being created by LAMCC.panel(). It means having compatible interface. See how controls use `control.panel.data.something` without asking? They require the panel (i.e. the `parent.panel or parent` from their constructor) to have a `data` table.

So you can't use just about any control as `parent`, it must at least have `.data`, or `.panel` that has it. The additional requirement to have a name seems sensible to me.

[sirinsidiator]

You are right. I should have read the function to the end
The documentation tells us two different things:

For manual control creation. You must handle anchoring of these controls, either to a LAM panel or a control of your choosing.

parent = userdata; the panel returned by the :RegisterOptionsPanel method

[joshmiller83]

How hard is it for someone who isn't an author to update an addon to r17 from r14 or r16? Is there a lot of changes or is it pretty much a simple drag'n'drop? I am not illiterate or anything as I have been in tech support and IT/IS for 12 years now but I am not skilled in LUA yet, or any other language anymore.

[Ayantir]

it's a simple copy paste.

[joshmiller83]

Originally Posted by Ayantir it's a simple copy paste.

Any more info?

[joshmiller83]

Also another question... I remember in WoW way back when (when I played that game) we could install addons without Libs and then put the Libs in the Main addon folder as addons themselves and then the addons would "include" the addon folder in looking for Libs? This made updating the Libs very easy as you only updated the Library Addon. Is this funtionalty available with LAM and ESO? Or is it a ZOS/ESO API limitation?

[Garkin]

Originally Posted by joshmiller83 Also another question... I remember in WoW way back when (when I played that game) we could install addons without Libs and then put the Libs in the Main addon folder as addons themselves and then the addons would "include" the addon folder in looking for Libs? This made updating the Libs very easy as you only updated the Library Addon. Is this funtionalty available with LAM and ESO? Or is it a ZOS/ESO API limitation?

In most cases yes. You can install LibAddonMenu-2.0 (LAM) as stand alone addon. However what is important, LAM library is loaded using the LibStub. This library will make sure that you have in memory always the latest available version. In other workds, you need just one addon which has embedded the latest version of LAM and all your addons will use this latest version.

[sirinsidiator]

Originally Posted by joshmiller83 Any more info?

1. Look at the list of addons that use LAM2 to see which addons you need update.
2. Download and extract the latest LAM2 version
3. Go to each addon folder and locate the folder that contains a file called LibAddonMenu-2.0 and a folder called controls
4. Delete these two and copy the new version.

Originally Posted by joshmiller83 Also another question... I remember in WoW way back when (when I played that game) we could install addons without Libs and then put the Libs in the Main addon folder as addons themselves and then the addons would "include" the addon folder in looking for Libs? This made updating the Libs very easy as you only updated the Library Addon. Is this funtionalty available with LAM and ESO? Or is it a ZOS/ESO API limitation?

Yes, you can simply install LAM2 via minion and update it whenever a new version is available.
At least once all versions before r17 have disappeared.

Right now the load order is important for the initialization because code was executed whenever a LAM2 file with a newer version than the previous was loaded into memory.
This should actually not be a problem when a standalone LAM is installed, but for some reason the OptionalDependsOn inside the addon manifest is not considered when ESO calculates the load order and the standalone LAM might get loaded at any time after another addon that includes LAM gets loaded.