Quantcast
Download
(38 Kb)
Download
Updated: 07/17/16 11:04 AM
Pictures
File Info
Compatibility:
Shadows of the Hist (2.5)
Dark Brotherhood (2.4)
Updated:07/17/16 11:04 AM
Created:02/14/14 10:28 PM
Downloads:36,980
Favorites:177
MD5:
2.4
LibAddonMenu  Popular! (More than 5000 hits)
Version: 2.0 r21
by: sirinsidiator, Seerah
Since I (sirinsidiator) have taken over development of LAM-2.0 I decided it will be in the best interest of everyone to make future development a group effort.
With the consent of Seerah I have put LAM-2.0 under The Artistic License 2.0 and created a github project in order to make collaborations possible.
I also want to thank everyone who participated in planning and realizing upcoming changes, especially votan, merlight and Garkin.

If you came here because a message in chat told you so,
then you are using an outdated addon that relies on an older version of LAM-2.0 which might not be compatible with ESO update 6.
But no need to panic. There are a few things you can do in order to get it to work again:
  1. Update your addons. Maybe the author already fixed the problem.
  2. Try to find out which addon uses the outdated version and ask for help in the comment section.
  3. Ask for help in our comment section.
  4. Replace LibAddonMenu-2.0 in all your addons with the newest version.

LibAddonMenu-2.0 is now released!
Your addons will continue to work under LAM-1.0, however that version of the library will no longer be receiving updates, and you will not receive any benefits of LAM-2.0.

** NOTE: If you are using a version of LAM-2.0 earlier than r17, please update your copy of the lib in the addon. This will avoid problems with loading future versions of LAM.**


LibAddonMenu-2.0 is a library to aid addon authors in creating a configuration GUI for their addons which is located in the game's Settings menu. It supports the ability to have all of a user's addon options located in the same panel.

You may see ZAM_Stats for an example of usage.


HOW TO USE:

--Including the library with your addon--
You may either embed the library and LibStub in your addon and load the files from your addon manifest, or have the library installed like any other normal addon.

If your addon embeds the library, you may place this line in your manifest file, just in case the user also has a standalone version installed.
Code:
## OptionalDependsOn: LibAddonMenu-2.0
If you are depending on the library being installed separately and are not embedding it, then you must include this line in your text file.
Code:
## DependsOn: LibAddonMenu-2.0
Either way you choose, LibStub will ensure that only one copy of the library (the newest revision) is loaded into memory.

When embedding the libary, remove the internal LibAddonMenu-2.0 folder from the main library download. I usually place my libraries in a sub-folder called "libs", but you may put them wherever you like in your addon directory. This is how I would then list the files in my manifest. (LAM2's widget controls are broken out into their own files to keep their code clean - this is why there is so many. Good thing you only have to copy-paste this once!)

Code:
libs\LibAddonMenu-2.0\LibAddonMenu-2.0.lua
libs\LibAddonMenu-2.0\controls\panel.lua
libs\LibAddonMenu-2.0\controls\submenu.lua
libs\LibAddonMenu-2.0\controls\button.lua
libs\LibAddonMenu-2.0\controls\checkbox.lua
libs\LibAddonMenu-2.0\controls\colorpicker.lua
libs\LibAddonMenu-2.0\controls\custom.lua
libs\LibAddonMenu-2.0\controls\description.lua
libs\LibAddonMenu-2.0\controls\dropdown.lua
libs\LibAddonMenu-2.0\controls\editbox.lua
libs\LibAddonMenu-2.0\controls\header.lua
libs\LibAddonMenu-2.0\controls\slider.lua
libs\LibAddonMenu-2.0\controls\texture.lua
libs\LibAddonMenu-2.0\controls\iconpicker.lua
(Don't forget to also embed LibStub and have it listed to load prior to LibAddonMenu!)


--Getting the library from LibStub (required)--
Lua Code:
  1. local LAM = LibStub:GetLibrary("LibAddonMenu-2.0")
  2. --OR--
  3. local LAM = LibStub("LibAddonMenu-2.0")
  4.      --returns a reference to the library table


Please see the LAM-2.0 wiki on github for guides and docs, as well as a list of differences between LAM-1.0 and LAM-2.0

Details on LAM2 data tables
2.0 r21
- fixed panel creation starting more than once when switching between different addon panels quickly (#40)
- fixed LAM.util getting wiped with each version load causing errors for many players (#44)
- fixed disabled controls not having the correct label color in some cases (#41)
- fixed controls not updating their own disabled state when their value changes (#51)
- added Japanese translation (thanks k0ta0uchi) (#45)
- added isDangerous flag for button controls (#50)
- when set to true it changes the text color of the button to red and opens a dialog which shows the label and the warning text before running the callback
- added new options for sliders and fixed some bugs (#49)
- autoSelect (boolean): when set to true it makes the input field select all text when it gains focus
- inputLocation (string): setting it to "right" will move the input field to the right side of the slider and make it slightly bigger. For aesthetic reasons this should only be used in custom panels and not in the addon menu
- clampInput (boolean): true by default and if set to false it allows the input values of the slider to exceed the min and max value
- for other internal code changes take a look at the git history

2.0 r20
- fixed empty panels not firing LAM-PanelControlsCreated (#32)
- removed height constraint of 2500 from submenus (#34)
- added two new callbacks LAM-PanelOpened and LAM-PanelClosed. Both pass the panel as their sole argument (#27)
- 'default' can now be a function in addition to a static value (#23)
- all labels (name, tooltip, warning, etc.) can now be a string id or function in addition to a static string (#22)
- updated LibStub to r4

2.0 r19
- made icon picker choicesTooltips array optional
- added support for custom panel objects without a GetWidth method (partially fixes #26)
- fixed controls not refreshing correctly when they are initialized with a boolean "false" on the disabled property (#35, thanks Randactyl)
- removed height constraint on the description control (#36, thanks KuroiLight)
- added "isExtraWide" property to editboxes, allowing them to utilize more space (#37, thanks KuroiLight)
- added "decimals" property to sliders to allow rounding values to x decimals (#38, implements #21, thanks KuroiLight)
- added mousewheel support for sliders (#39, implements #30, thanks KuroiLight)

2.0 r18
- major overhaul of the addon menu style (thanks votan & merlight)
- NOTE: the menu is now a bit wider than before, if you created custom elements you might need to update them accordingly
- added search box to addon list (thanks votan & merlight)
- new icon picker widget
- removed micro freeze when opening a menu with many options for the first time
- changed tooltip property to accept functions that return a string (thanks Ayantir)
- changed the label on the defaults button and menu to avoid a grammar mistake in the french localization (thanks Ayantir)
- updated LibStub to r3 (support for '.' in minor version string, e.g. "17.5")

2.0 r17
- updated for changes in 100011
- fixed OpenToPanel function
- fixed possible error with combobox names
- half width control no longer have a fixed height and instead scale automatically now
- changed controls to no longer use top level windows
- fixed problems with the loading order and added warning if an old version gets initialized first
A big thank you to everyone who helped making these changes, especially votan, merlight and Garkin!

2.0 r16
- updated for changes in 100010
- thanks to Garkin for alerting me of changes needed and for testing on the test server
- Spanish support added, translation provided by Luisen75 for their Spanish project

2.0 r14
- fixed bug where the LAM-RefreshPanel callback was being registered with CALLBACK_MANAGER multiple times
- fixed highlighting of entries in the game Settings menu (Addon Settings now properly highlights and other entries go back to normal)

2.0 r13
- one last bug ran out from anunder the dresser - I smashed it hopefully!

2.0 r12
- fix one bug another shows up...

2.0 r11
- don't overwrite widgets list if table already exists (in case an external lib or addon registers a new widget type)
- headers, descriptions, submenus and custom widgets now have the ability to update their text when the panel and other controls refresh (simply change the name/text in the controlData table)
- custom controls now have the ability to refresh with other controls and your panel - there is a new optional field in the data table called refreshFunc (when the panel refreshes, this function will be called)

2.0 r10
- fixed display of warning icon for dropdown controls
- update LibStub.lua

2.0 r9
- added Russian locale support for RuESO project
- fixed anchoring issue with addon list (addon names are now properly in the scroll frame, so the few of you with tons installed should have no issue any longer)
- added ability to close submenus from the bottom of the submenu (there is a small strip along the bottom of the submenu that is clickable)
- edited each control to better support custom-created UIs via LAM and the parent passed through to the create functions

2.0 r8
- changed border texture around panel and addon list
- expanded maximum size of submenus from 1500 to 2500

2.0 r7
- shortened game menu entry for French and German localizations (so the text doesn't get cut off)
- fixed checkbox label coloring bug (when a checkbox that is set to "off" is re-enabled by another setting)
- fixed multi-line editbox bug (where text didn't display)
- added mousewheel scrolling for multi-line editboxes

2.0 r6
- added "LAM-PanelControlsCreated" callback when you panel has been shown for the first time and your controls have now been created
- fixed duplicate Addon Settings panels when you have a newer version of LAM overwriting an older version
- finished localizing stuff that wasn't localized yet
- added "sort" field to dropdown control

2.0 r5
- fix RefreshPanel function so that all controls now update
- add RefreshPanel call to ForceDefaults function

2.0 r4
- fix for me being an idiot. Sorry guys ><

2.0 r3
- fixed checkboxes making a sound when just refreshing
- fixed error when the lib is loaded standalone, but no addons are registered with it
- fixed error when LAM updates itself to a newer version (won't try to create two of the same frame)

2.0 r2
- LAM-2.0 is now released! See http://www.esoui.com/portal.php?&id=5&pageid=10 for a list of differences between LAM1 and LAM2, as well as a guide for usage and the library's docs

-----------------
1.0 r8
- updated APIVersion to 100004
- changed submenu so scroll bar doesn't overlap contents
- submenu should hopefully no longer occasionally show up behind the options panel

1.0 r7
- the defaults button now properly hides for each panel (Note: the keybind still works, I can't seem to get rid of that, but at least the prompt is hidden now)
- LAM now supports sub menus! See the description page for docs on usage

1.0 r6
- copy/paste fail when changing the name of an arg. Description titles will no longer hide from you.

1.0 r5
- exposed the widgets created via return

1.0 r4
-new widget: Description

1.0 r3
-fixed error with color picker in new patch

1.0 r2
-fixed bug when more than one addon panel is created
Archived Files (19)
File Name
Version
Size
Author
Date
2.0 r20
41kB
sirinsidiator
03/26/16 10:45 AM
2.0 r19
37kB
sirinsidiator
02/24/16 12:24 PM
2.0 r18
36kB
sirinsidiator
06/14/15 01:12 PM
2.0 r17
30kB
sirinsidiator
02/22/15 11:09 AM
2.0 r16
27kB
sirinsidiator
11/02/14 02:03 PM
2.0 r14
26kB
Seerah
07/27/14 10:17 PM
2.0 r13
26kB
Seerah
07/20/14 09:35 PM
2.0 r12
26kB
Seerah
07/20/14 07:55 PM
2.0 r11
26kB
Seerah
07/19/14 02:49 PM
2.0 r10
25kB
Seerah
07/13/14 09:18 PM
2.0 r9
25kB
Seerah
07/05/14 06:55 PM
2.0 r8
25kB
Seerah
06/22/14 09:47 PM
2.0 r7
25kB
Seerah
06/15/14 05:17 PM
2.0 r6
25kB
Seerah
06/13/14 11:28 PM
2.0 r5
25kB
Seerah
06/12/14 10:32 PM
2.0 r4
25kB
Seerah
06/11/14 08:56 PM
2.0 r3
25kB
Seerah
06/11/14 07:49 PM
2.0 r2
24kB
Seerah
06/10/14 10:06 PM
1.0 r8
6kB
Seerah
05/24/14 10:01 PM


Post A Reply Comment Options
Unread 07/11/16, 12:47 PM  
Enodoc
AddOn Author - Click to view AddOns

Forum posts: 24
File comments: 49
Uploads: 2
Re: Re: Re: Re: Disable a button

Originally Posted by sirinsidiator
Originally Posted by Enodoc
Originally Posted by sirinsidiator
You can manually refresh your panel by calling
Lua Code:
  1. CALLBACK_MANAGER:FireCallbacks("LAM-RefreshPanel", panel)
where panel is the return value from RegisterAddonPanel, but in your case it should not be necessary. As long as you have the registerForRefresh flag enabled in your panel it should refresh itself when necessary.
Great, thanks! registerForRefresh is enabled, but clicking a button doesn't seem to trigger a refresh, so firing that callback is likely what I need. Thanks again!
That's strange. The button itself already fires the callback when you click it:
Lua Code:
  1. button:SetHandler("OnClicked", function(self, ...)
  2.         buttonData.func(self, ...)
  3.         if control.panel.data.registerForRefresh then
  4.             cm:FireCallbacks("LAM-RefreshPanel", control)
  5.         end
  6.     end)
Agreed, it's a bit odd. Putting the callback in worked though, so thanks for that!
__________________
ESOTU Community Ambassador

UESP: The Unofficial Elder Scrolls Pages - A collaborative source for all knowledge on the Elder Scrolls series since 1995
Report comment to moderator  
Reply With Quote
Unread 07/11/16, 04:58 AM  
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view AddOns

Forum posts: 652
File comments: 432
Uploads: 22
Re: Re: Re: Disable a button

Originally Posted by Enodoc
Originally Posted by sirinsidiator
You can manually refresh your panel by calling
Lua Code:
  1. CALLBACK_MANAGER:FireCallbacks("LAM-RefreshPanel", panel)
where panel is the return value from RegisterAddonPanel, but in your case it should not be necessary. As long as you have the registerForRefresh flag enabled in your panel it should refresh itself when necessary.
Great, thanks! registerForRefresh is enabled, but clicking a button doesn't seem to trigger a refresh, so firing that callback is likely what I need. Thanks again!
That's strange. The button itself already fires the callback when you click it:
Lua Code:
  1. button:SetHandler("OnClicked", function(self, ...)
  2.         buttonData.func(self, ...)
  3.         if control.panel.data.registerForRefresh then
  4.             cm:FireCallbacks("LAM-RefreshPanel", control)
  5.         end
  6.     end)
Report comment to moderator  
Reply With Quote
Unread 07/11/16, 03:27 AM  
Enodoc
AddOn Author - Click to view AddOns

Forum posts: 24
File comments: 49
Uploads: 2
Re: Re: Disable a button

Originally Posted by sirinsidiator
You can manually refresh your panel by calling
Lua Code:
  1. CALLBACK_MANAGER:FireCallbacks("LAM-RefreshPanel", panel)
where panel is the return value from RegisterAddonPanel, but in your case it should not be necessary. As long as you have the registerForRefresh flag enabled in your panel it should refresh itself when necessary.
Great, thanks! registerForRefresh is enabled, but clicking a button doesn't seem to trigger a refresh, so firing that callback is likely what I need. Thanks again!
__________________
ESOTU Community Ambassador

UESP: The Unofficial Elder Scrolls Pages - A collaborative source for all knowledge on the Elder Scrolls series since 1995
Report comment to moderator  
Reply With Quote
Unread 07/10/16, 12:47 PM  
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view AddOns

Forum posts: 652
File comments: 432
Uploads: 22
Re: Disable a button

Originally Posted by Enodoc
Is there an easy way to get a "button" to refresh the panel when clicked?

Lua Code:
  1. {
  2.             type = "button",
  3.             name = GetString(BUTTON_NAME),
  4.             tooltip = GetString(BUTTON_TOOLTIP),
  5.             func = function() ButtonBool = true end,
  6.             disabled = function() return (ButtonBool == true) end,
  7.             width = "half",
  8.         },
The button is being used as an enabler for subsequent controls, through those having
Lua Code:
  1. disabled = function() return not ButtonBool end,
and the button itself shouldn't be clickable again.

It refreshes when a "checkbox" is toggled, or if you click to another add-on and back, but it would be good if there was something I could call in the button function that would cause it to refresh itself. Thanks!
You can manually refresh your panel by calling
Lua Code:
  1. CALLBACK_MANAGER:FireCallbacks("LAM-RefreshPanel", panel)
where panel is the return value from RegisterAddonPanel, but in your case it should not be necessary. As long as you have the registerForRefresh flag enabled in your panel it should refresh itself when necessary.
Last edited by sirinsidiator : 07/10/16 at 12:51 PM.
Report comment to moderator  
Reply With Quote
Unread 07/09/16, 03:47 PM  
Enodoc
AddOn Author - Click to view AddOns

Forum posts: 24
File comments: 49
Uploads: 2
Disable a button

Is there an easy way to get a "button" to refresh the panel when clicked?

Lua Code:
  1. {
  2.             type = "button",
  3.             name = GetString(BUTTON_NAME),
  4.             tooltip = GetString(BUTTON_TOOLTIP),
  5.             func = function() ButtonBool = true end,
  6.             disabled = function() return (ButtonBool == true) end,
  7.             width = "half",
  8.         },
The button is being used as an enabler for subsequent controls, through those having
Lua Code:
  1. disabled = function() return not ButtonBool end,
and the button itself shouldn't be clickable again.

It refreshes when a "checkbox" is toggled, or if you click to another add-on and back, but it would be good if there was something I could call in the button function that would cause it to refresh itself. Thanks!
__________________
ESOTU Community Ambassador

UESP: The Unofficial Elder Scrolls Pages - A collaborative source for all knowledge on the Elder Scrolls series since 1995
Last edited by Enodoc : 07/09/16 at 04:00 PM.
Report comment to moderator  
Reply With Quote
Unread 06/20/16, 11:19 AM  
Sasky
AddOn Author - Click to view AddOns

Forum posts: 239
File comments: 86
Uploads: 4
Originally Posted by votan
Originally Posted by merlight
1) if there is no other add-on with properly released LAM, the user will end up with no LAM at all
I don't think, that would be wrong. If the addon, embedding an unreleased github version, is the only one using LAM2, causing an error is correct in my opinion.
Maybe the check should cause the Lua error dialog?
Sorry about that. Fixing it now that I'm back from travel. However, I'm not sure this doesn't point to an underlying issue, since the Git difference when I forced it to the released r20 version had
  1. The version number at 20
  2. An April Fools snippit added
  3. A DDS used by that snippet added
I'm not sure what in there would cause the crash.


--------------------------------------------------------------------------------------------------


When adding those changes, the Code Analysis in IntelliJ found an issue with the minified April Fools snippet:
Code:
Warning:(835) Unbalanced number of expressions in assignment
Snippet highlighted:
Lua Code:
  1. local f,g,h,i,j,k,l,m=string.rep,string.format,math.floor,MAIL_MANAGER_GAMEPAD,MAIL_INBOX,zo_callLater,IsInGamepadPreferredMode;
Looks like the 'm' is extra there.


--------------------------------------------------------------------------------------------------


A couple other points you could do in case someone pulls the Github:
- Have separate dev/release branches with the default to release so it is safe to use. Better yet if the main branch can be usable as a git submodule/subtree.

- Add an additional file in the explicit LAM addon (ie "testVersioning.lua") and force update the library version:
Lua Code:
  1. LibStub:NewLibrary("LibAddonMenu-2.0", 9999)
Putting this in a separate file will help ensure it isn't pulled in. So it'll load the addon as r20 then bump the version number to testing and go from there.
Report comment to moderator  
Reply With Quote
Unread 06/09/16, 07:27 AM  
votan
 
votan's Avatar
AddOn Author - Click to view AddOns

Forum posts: 298
File comments: 442
Uploads: 14
Originally Posted by merlight
1) if there is no other add-on with properly released LAM, the user will end up with no LAM at all
I don't think, that would be wrong. If the addon, embedding an unreleased github version, is the only one using LAM2, causing an error is correct in my opinion.
Maybe the check should cause the Lua error dialog?
__________________
@votan73 (EU - megaserver)
Report comment to moderator  
Reply With Quote
Unread 06/09/16, 07:24 AM  
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view AddOns

Forum posts: 652
File comments: 432
Uploads: 22
Originally Posted by merlight
Originally Posted by sirinsidiator
I was thinking of setting a saved variable in an additional file of the standalone which will then set the version to 999 for developers.
If someone bundles it, the file doesn't get loaded and the default version is 0. It also needs to be included by hand at least once so it works.
You mean a global var, right? Then it becomes almost what I suggested in the past, with only a small change.

Lua Code:
  1. local MAJOR, MINOR = "LibAddonMenu-2.0", _LAM2_VERSION_NUMBER or -1

And set _LAM2_VERSION_NUMBER = 999 in the other file (loaded first, in stand-alone only).

I think this might be better than my previous suggestion, because there were two issues with it:
1) if there is no other add-on with properly released LAM, the user will end up with no LAM at all
2) you'd have to change all control/*.lua, add LibStub.SILENT and check that LAM is not nil first

Whereas the solution with global LAM version in stand-alone will just work, including the case where there's no other LAM version (version -1 is the highest in this case).
Right, I guess I could just define it directly and skip the saved variable. For the release on ESOUI the build script will just replace that part (like it does now) and remove the extra file, so only the github standalone will be version 999 and as soon as it is bundled it will become -1 and never load unless it is the only LAM copy available.
Report comment to moderator  
Reply With Quote
Unread 06/09/16, 07:03 AM  
merlight
AddOn Author - Click to view AddOns

Forum posts: 636
File comments: 207
Uploads: 12
Originally Posted by sirinsidiator
I was thinking of setting a saved variable in an additional file of the standalone which will then set the version to 999 for developers.
If someone bundles it, the file doesn't get loaded and the default version is 0. It also needs to be included by hand at least once so it works.
You mean a global var, right? Then it becomes almost what I suggested in the past, with only a small change.

Lua Code:
  1. local MAJOR, MINOR = "LibAddonMenu-2.0", _LAM2_VERSION_NUMBER or -1

And set _LAM2_VERSION_NUMBER = 999 in the other file (loaded first, in stand-alone only).

I think this might be better than my previous suggestion, because there were two issues with it:
1) if there is no other add-on with properly released LAM, the user will end up with no LAM at all
2) you'd have to change all control/*.lua, add LibStub.SILENT and check that LAM is not nil first

Whereas the solution with global LAM version in stand-alone will just work, including the case where there's no other LAM version (version -1 is the highest in this case).
Report comment to moderator  
Reply With Quote
Unread 06/09/16, 06:57 AM  
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view AddOns

Forum posts: 652
File comments: 432
Uploads: 22
Originally Posted by votan
Isn't this a bit too late?
If I'm not wrong, saved variables are available starting with the EVENT_ADD_ON_LOADED, but at this moment the LibStub check has been passed already and all functions are updated.
I like the idea of merlight.
I was under the impression that they are always available, but I may be wrong. If it is not possible, I will stick to merlight's proposal.
Report comment to moderator  
Reply With Quote
Unread 06/09/16, 06:46 AM  
votan
 
votan's Avatar
AddOn Author - Click to view AddOns

Forum posts: 298
File comments: 442
Uploads: 14
Originally Posted by sirinsidiator
I was thinking of setting a saved variable in an additional file of the standalone which will then set the version to 999 for developers.
If someone bundles it, the file doesn't get loaded and the default version is 0. It also needs to be included by hand at least once so it works.
Isn't this a bit too late?
If I'm not wrong, saved variables are available starting with the EVENT_ADD_ON_LOADED, but at this moment the LibStub check has been passed already and all functions are updated.
I like the idea of merlight.
__________________
@votan73 (EU - megaserver)
Report comment to moderator  
Reply With Quote
Unread 06/09/16, 06:36 AM  
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view AddOns

Forum posts: 652
File comments: 432
Uploads: 22
Originally Posted by merlight
Originally Posted by sirinsidiator
I'll have to think of some measure to prevent it from happening again and again and I already have an idea.
You could probably bail out if it's not installed stand-alone, something like:
Lua Code:
  1. if MINOR >= 999 then
  2.     pathToStandAlone = "AddOns/LibAddonMenu-2.0/LibAddonMenu-2.0/LibAddonMenu-2.0.lua"
  3.     fakeError = pcall(error, "test", 2)
  4.     if not fakeError:find(pathToStandAlone, 1, true) then
  5.         -- not installed stand-alone, refuse to load
  6.         -- maybe queue a message in case there's no other add-on with valid LAM
  7.         return
  8.     end
  9. end
I was thinking of setting a saved variable in an additional file of the standalone which will then set the version to 999 for developers.
If someone bundles it, the file doesn't get loaded and the default version is 0. It also needs to be included by hand at least once so it works.
Last edited by sirinsidiator : 06/09/16 at 06:37 AM.
Report comment to moderator  
Reply With Quote
Unread 06/09/16, 06:26 AM  
merlight
AddOn Author - Click to view AddOns

Forum posts: 636
File comments: 207
Uploads: 12
Originally Posted by sirinsidiator
I'll have to think of some measure to prevent it from happening again and again and I already have an idea.
You could probably bail out if it's not installed stand-alone, something like:
Lua Code:
  1. if MINOR >= 999 then
  2.     pathToStandAlone = "AddOns/LibAddonMenu-2.0/LibAddonMenu-2.0/LibAddonMenu-2.0.lua"
  3.     fakeError = pcall(error, "test", 2)
  4.     if not fakeError:find(pathToStandAlone, 1, true) then
  5.         -- not installed stand-alone, refuse to load
  6.         -- maybe queue a message in case there's no other add-on with valid LAM
  7.         return
  8.     end
  9. end
Last edited by merlight : 06/09/16 at 06:30 AM.
Report comment to moderator  
Reply With Quote
Unread 06/07/16, 04:44 AM  
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view AddOns

Forum posts: 652
File comments: 432
Uploads: 22
Originally Posted by dorrino
Here's the source of the problem:

Latest veriosn of CyrHUD 1.3.0 uses LibAddonMenu version from your Github

Code:
local MAJOR, MINOR = "LibAddonMenu-2.0", 999 -- only for test purposes. releases will get a smaller number
And it messes up other addons relying on LibAddonMenu.

Obviously copying LibAddonMenu v.20 over v.999 in CyrHUD folder fixed it.

Now i'm gonna post this in CyrHUD comments.

BTW, why addons don't use the LibAddonMenu version from their respected folders? I understand that your test version have higher version number and thus higher priority, but why should it matter for other addon if they're explicitely told to use both libstub and libaddonmenu from within their folders?
Thanks for looking that far into it.
The github version is not intended to be released in addons, but it has already happened more than once. I'll have to think of some measure to prevent it from happening again and again and I already have an idea.

I am not 100% sure why libraries are set up like they are. As far as I am aware LibStub has been copied over from WOW where it has worked like this for years. Two reasons I can think of are that it is much easier to get a new version out there, because not every single addon has to update the bundled lib immediately and that it is to avoid problems with shared resources, because older versions may access them in a way that causes problems in a newer version. It may also just be that nobody really thought about how to do it properly.
Report comment to moderator  
Reply With Quote
Unread 06/06/16, 07:44 PM  
dorrino
AddOn Author - Click to view AddOns

Forum posts: 8
File comments: 54
Uploads: 4
Originally Posted by sirinsidiator
It works fine for me. The error also doesn't make sense. Is there no other error before that one?
Can you please try what happens when you run
Code:
/script d(LibStub("LibAddonMenu-2.0").util.GetIconPickerMenu())
in the chat after you freshly loaded the UI?
Code:
[string "d(LibStub("LibAddonMenu-2.0").util.GetIconPickerMenu())"]:1: function expected instead of nil
stack traceback:
	[string "d(LibStub("LibAddonMenu-2.0").util.GetIconPickerMenu())"]:1: in function '(main chunk)'
	EsoUI/Ingame/SlashCommands/SlashCommands_Shared.lua:5: in function 'fn'
	EsoUI/Ingame/SlashCommands/SlashCommands_Shared.lua:62: in function 'DoCommand'
	EsoUI/Ingame/ChatSystem/SharedChatSystem.lua:1806: in function 'SharedChatSystem:SubmitTextEntry'
	EsoUI/Ingame/ChatSystem/SharedChatSystem.lua:2489: in function 'ZO_ChatTextEntry_Execute'
	14406795741938050902:3: in function '(main chunk)'
	(tail call): ?
As expected. I checked Item Saver comments section and there's a guy there with the same problem. So, having confirmations that it's not me and it's not normal (quickly checked iconpicked.lua code and i wasn't able to figure out how that function could be nil) i went on and investigated.

Here's the source of the problem:

Latest veriosn of CyrHUD 1.3.0 uses LibAddonMenu version from your Github

Code:
local MAJOR, MINOR = "LibAddonMenu-2.0", 999 -- only for test purposes. releases will get a smaller number
And it messes up other addons relying on LibAddonMenu.

Obviously copying LibAddonMenu v.20 over v.999 in CyrHUD folder fixed it.

Now i'm gonna post this in CyrHUD comments.

BTW, why addons don't use the LibAddonMenu version from their respected folders? I understand that your test version have higher version number and thus higher priority, but why should it matter for other addon if they're explicitely told to use both libstub and libaddonmenu from within their folders?
Last edited by dorrino : 06/06/16 at 07:59 PM.
Report comment to moderator  
Reply With Quote
Post A Reply



Category Jump: