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. |
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? |
Quote:
|
For the dropbox widget:
Lua Code:
Lua Code:
As I have written week ago in comments to LAM, simple and easy way is: Lua Code:
|
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. Quote:
|
Quote:
Code:
NoThankYou.lua: |
Quote:
Any particular reason why it is so important? Did we miss something? |
Quote:
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: Lua Code:
Lua Code:
|
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. |
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: Lua Code:
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. |
You are right. I should have read the function to the end :D
The documentation tells us two different things: Quote:
Quote:
|
LAM2 r17?
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.
|
it's a simple copy paste.
|
Quote:
|
Libs as Seperate Addons?
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?
|
Quote:
|
Quote:
Quote:
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. |
All times are GMT -6. The time now is 10:22 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2014 - 2022 MMOUI