Elsia gave a very basic example. The callbacks from LSM-3.0 will rarely get called so its not that big of a deal to still have them registered while an addon is in standby. The callbacks both return the mediatype and name as args but in the most basic of uses you don't need to worry about the args since you can just re-fetch everything when the callbacks are fired. More advanced uses might care about which mediatype and the name of the media before doing any fetching.
So you do LSM:Fetch() on PLAYER_LOGIN (or some other event that fires after all addons load) and then do LSM:Fetch() after all ADDON_LOADED's that fire after that first event? Ok that does work without needed to use the media registered callback but you still aren't doing anything for when the global override changes, and LSM-2.0 doesn't have any way to tell you to LSM:Fetch() again when the user changes the global override. LSM-3.0 has a callback for when the user changes the global override so that you can do LSM:Fetch() again (SML-1.0 fired an event too when the global override was changed, this is the major API flaw in LSM-2.0 that kept it from being converted to using CBH-1.0 and requiring a major version number change).
Most people haven't tried to do anything like you have to work around the issue and instead just do LSM:Fetch() once. The worst are the 'upgrades' that do nothing but change the name. I don't know why some people don't understand that major version number increases happen when API changes, so only changing the name gets them on my shitlist and I will revert the changes (if I can) if its a completely broken upgrade like CooldownCount recently did (which broke every mod that uses LSM-3.0 when CooldownCount was loaded first with embedded libraries).
I assume you have the 'SharedMedia', try adding your mod as a reqdep to SharedMedia so that SharedMedia loads after your mod then see how much media is available in your addon. You can also try making SharedMedia LoD then loading it after you login. And no, adding SharedMedia as an optdep to your own addon is not a solution since any addon can register media. SharedMediaLib-1.0 had callbacks too btw, they were called events from AceEvent-2.0. Media getting registered after your addon has loaded and done LSM:Fetch(...) will always have issues depending on load order unless you use Callbacks.
From what I have learned in this thread is that
- there are many gotchas with lsm, and using lsm 3 is the most complicated choice.
- the only difference between lsm 2 and 3 are asian fonts and callbacks... both features that I don't need.
So this thread perfectly suggested the use of lsm-2.0 for me.
CALLBACKS ARE A REQUIRED PART OF THE ENTIRE SHAREDMEDIA IDEA! EVERYBODY MUST USE THEM! LSM-2.0s LACK OF COMPLETE CALLBACK API IS A DESIGN FLAW IN THE LIBRARY MEANING YOU SHOULDN'T USE IT!
Why do people not understand this. Makes me want to svn del everything else just to force people to use LSM-3.0 so they'll stop thinking they don't need to upgrade.
Can you tell us how to use it so that it is compatible with LSM-3 and LSM-2 and LSM-1?
Right now its a mess, and we are forced to call LoadAddOn on LSM-3 or LSM-2 (Whichever we find first), register with all 3, embed LSM1 and LSM2/3.
If we want to be compatible. All that has to be done - unless you can tell me a better way.
No you just use LSM3, don't use any of the others even if found.
For the simplest way to use callbacks just make a function that refetches all the media you use without even looking at any of the arguments given to it and register it to both the register and setglobal callback.
LSM-2.0 has a callback, but its completely wrong of what it should be and it only has one instead of two like it should have, fixing LSM-2.0 would break the API. The obvious answer here is that everybody should use LSM-3.0 so that LSM-2.0 and SML-1.0 will die like Surface did so that maybe we can get a single lib in use again instead of multiple ones because people don't upgrade their addons.