LibEventHandler : Libraries : Elder Scrolls Online AddOns

(7 Kb)

Download

Updated: 08/08/24 11:45 PM

Add Favorite

Install Help

Portal

Bugs

Features

Compatibility:	Update 43 (10.1.0) Gold Road (10.0.0)
Updated:	08/08/24 11:45 PM
Created:	08/10/16 11:53 PM
Monthly downloads:	3,367
Total downloads:	136,233
Favorites:	10
MD5:
Categories:	Libraries, Developer Utilities

10.1.0

LibEventHandler Popular! (More than 5000 hits)

Version: 1.3.6

by: Justinon, Calamath

LibEventHandler. A better event manager.

For Devs Only!
While although Zenimax's EVENT_MANAGER may do the trick for creating simplistic addons, it has some restrictions that need to be bypassed in some cases.
LibEventHandler helps you with that.

The main purpose of this library is to allow for a more versatile event handler than what ZOS provides
through their EVENT_MANAGER. LibEventHandler expands the limitation of an event being incarcerated with
only one function, to now being able to be linked to as many different functions as needed. In addition,
it allows for the firing and registering of local events that you create within your addon. Together,
these features enable this powerful tool to allow the developer to not only be more flexible with event
managing, but also to be more clean, concise, and acyclical with code.

For a ton of information on how to use this library, including how to initialize the library, and learn the API methods, check out the LibEventHandler Wiki Page for all you need to know.

*The content of the original wiki page is outdated, so redirecting to the new wiki page.

Patch maintenance and improvement by Calamath.

Calamath Note:

Experienced authors may know we can register different handlers for the same event in one add-on by giving different strings for namespace arguments. The original author intended to avoid unwanted conflicts and register multiple handlers more easily by this library without managing such namespace strings.
Experienced authors may know we can implement custom events by callback object.
The original author intended to provide the same interface as RegisterForEvent so novice add-on developers could easily use it.
Experienced authors may notice we could substitute the library features with the ZOS class library. If you are considering using the library in your new project, please determine if you should rely on this library.

Version 1.3.6: (Calamath)
- Updated API version to 101043 (ESO 10.1.x : Update 43)

Version 1.3.5: (Calamath)
- Updated API version to 101042 (ESO 10.0.x : Gold Road)

Version 1.3.4: (Calamath)
- Updated API version to 101039 (ESO 9.1.x : Update 39)

Version 1.3.3: (Calamath)
- Updated API version to 101038 (ESO 9.0.x : Necrom)

Version 1.3.2: (Calamath)
- Updated API version to 101037 (ESO 8.3.x : Scribes of Fate)

Version 1.3.1: (Calamath)
- Updated API version to 101036 (ESO 8.2.x : Firesong)

Version 1.3.0: (Calamath)
- Updated API version to 101035 (ESO 8.1.x : Lost Depths)

Version 1.2.99: (Calamath)
- Updated API version to 101034 (ESO 8.0.x : High Isle)

Version 1.2.98: (Calamath)
- Updated API version to 101033 (ESO 7.3.x : Ascending Tide)

Version 1.2.97: (Calamath)
- Updated API version to 101032 (ESO 7.2.x : Deadlands)

Version 1.2.96: (Calamath)
- Updated API version to 101031 (ESO 7.1.x : Waking Flame)

Version 1.2.95: (Calamath)
- Updated API version to 100035 (ESO 7.0.x : Blackwood)

Version 1.2.94: (Calamath)
- Updated API version to 100034 (ESO 6.3.x : Flames of Ambition)

Version 1.2.93: (Calamath)
- Updated API version to 100033 (ESO 6.2.x : Markarth)

Version 1.2.92: (Calamath)
- Updated API version to 100032 (ESO 6.1.x : Stonethorn)

Version 1.2.91: (Calamath)
- Updated API version to 100031 (ESO 6.0.x : Greymoor)

Version 1.2.90: (Calamath)
- LibEventHandler library now has its own manifest file and a global variable LibEventHandler for direct access.
- Updated API version to 100029 (ESO 5.2.5 : Dragonhold)
- LibDebugLogger has been newly added to OptionalDependsOn in the add-on manifest file.
- Moved debug message output from UI chat to LibDebugLogger. From now on, we add-on authors and contributers will look at the debug log with the DebugLogViewer add-on.

----------------------------------------------------------------------------------------
The following are changes to the standard version by original author Justinon.
----------------------------------------------------------------------------------------

Version 1.2:

- Removed a print statement

Version 1.1:

- Changed async to allow for user input for the delay time as opposed to hard codes half a second. Still accepts boolean values

Optional Files (0)

Archived Files (15)

File Name	Version	Size	Uploader	Date
LibEventHandler	1.3.5	7kB	Calamath	05/20/24 03:14 AM
LibEventHandler	1.3.4	7kB	Calamath	07/30/23 03:33 AM
LibEventHandler	1.3.3	7kB	Calamath	05/20/23 10:01 PM
LibEventHandler	1.3.2	7kB	Calamath	03/17/23 07:26 PM
LibEventHandler	1.3.1	7kB	Calamath	10/27/22 09:15 AM
LibEventHandler	1.3.0	7kB	Calamath	08/22/22 03:04 AM
LibEventHandler	1.2.99	7kB	Calamath	04/21/22 04:35 AM
LibEventHandler	1.2.98	7kB	Calamath	02/20/22 04:21 AM
LibEventHandler	1.2.97	7kB	Calamath	10/08/21 11:59 PM
LibEventHandler	1.2.96	7kB	Calamath	08/07/21 08:48 PM
LibEventHandler	1.2.95	7kB	Calamath	05/24/21 09:55 PM
LibEventHandler	1.2.94	7kB	Calamath	05/19/21 11:21 AM
LibEventHandler	1.2	5kB	Calamath	05/19/21 11:19 AM
LibEventHandler	1.1	41kB	Justinon	08/14/16 10:36 PM
LibEventHandler	1.0	5kB		08/10/16 11:53 PM

Comment Options

05/19/21, 11:53 AM
Calamath Forum posts: 42 File comments: 251 Uploads: 7	Release note : Release Note : I will upload maintenance releases on behalf of the original author Justinon under the Artistic License 2.0 I've also released version 1.2, the original author forgot to upload here. This add-on library has been discontinued for a long time, so there may be multiple variants by different authors. Until the original author returns, we would like to integrate the design changes of the modified versions in the following GitHub repository. - Calamath Instructions for add-on authors: [COMPATIBILITY-BREAKING CHANGE] As of version 1.2.90, LibStub is no longer used. Instead, the global variable LibEventHandler has been added for direct access to the library. Therefore, it is necessary to rewrite as follows. Lua Code: -- YOUR ADD-ON MANIFEST FILE -- before ## OptionalDependsOn: LibEventHandler libs\LibStub\LibStub.lua libs\LibEventHandler\LibEventHandler.lua -- after (DELETE ABOVE and REPLACE this one) ## DependsOn: LibEventHandler Lua Code: -- YOUR ADD-ON CODE -- before local LEH = LibStub:GetLibrary("LibEventHandler-1.2") -- after local LEH = LibEventHandler Last edited by Calamath : 05/19/21 at 09:07 PM.

08/25/23, 06:42 PM

Calamath

Forum posts: 42

File comments: 251

Uploads: 7

Originally Posted by Baertram

Thanks for the info, understood that now after your details. And I'm totally fine if you are "not improving it"

I always wondered why this lib exists. I say it's because of the "custom events that could be added with it", or ith might have other benefits which I do not know yet.

Exactly.
We can implement custom events by callback object.
Perhaps the original author wanted to provide the same interface as RegisterForEvent so that novice add-on developers could easily use it.
I still maintain this library addon today because it was used in the LorePlay addon I maintain.
In a way, it's like a Git support branch.

So, I would say, there is no need to use this library in our new projects.

Last edited by Calamath : 08/25/23 at 06:49 PM.

08/25/23, 12:14 PM

Baertram

Super Moderator

Forum posts: 5177

File comments: 6251

Uploads: 78

Thanks for the info, understood that now after your details. And I'm totally fine if you are "not improving it"

I always wondered why this lib exists. I say it's because of the "custom events that could be added with it", or ith might have other benefits which I do not know yet.

Originally Posted by Calamath

Originally Posted by Baertram

Hi Calamth,

I read the Wiki about this lib and saw this info:

Code:

LibEventHandler's RegisterForEvent allows for any number of functions to be registered to a given event, instead of only one like ZOS restricts. So register away, and have multiple different files be able to track a single event.

Maybe I missundertand that but isn't this missinforming the users/devs as ZOs EVENT_MANAGER events can register multiple functions to the same event too?
They are just called after another, by load order of the addons / registered events.
As long as the unique identifier passed in is different you can e.g. call EVENT_WHATEVER like 100 times in your same addon.

If this isn't the thing the text explains and LibEventHandler does something differently the description of the addon and Wiki should be adopted to explain it better, imo

Hi Baertram, thanks for reading this old add-on wiki.
I think the original author has an idea that we add-on authors should use the string of the add-on name in principle for the namespace argument of RegisterForEvent method.
When using the same namespace string, we can only register one handler for each event; subsequent attempts to register another handler with the same namespace string will be rejected.
In the wiki text, I believe he meant to say that kind of inconvenience.

The original author would have sought a way to avoid unwanted conflicts and register multiple handlers easily by this library.

However, as you point out, we know that we can register different handlers for the same event in one add-on by giving different strings for namespace.
So the wiki content is certainly inaccurate. Well, it is better to correct it so as not to cause misunderstanding.

BTW, this library does not include any advanced features such as sorting the execution order of multiple event handlers.
Your understanding is correct. I have no plans to improve this add-on.

08/25/23, 10:40 AM

Calamath

Forum posts: 42

File comments: 251

Uploads: 7

Originally Posted by Baertram

Hi Calamth,

I read the Wiki about this lib and saw this info:

Code:

LibEventHandler's RegisterForEvent allows for any number of functions to be registered to a given event, instead of only one like ZOS restricts. So register away, and have multiple different files be able to track a single event.

BTW, this library does not include any advanced features such as sorting the execution order of multiple event handlers.
Your understanding is correct. I have no plans to improve this add-on.

08/25/23, 05:07 AM
Baertram Super Moderator Forum posts: 5177 File comments: 6251 Uploads: 78	Hi Calamth, I read the Wiki about this lib and saw this info: Code: LibEventHandler's RegisterForEvent allows for any number of functions to be registered to a given event, instead of only one like ZOS restricts. So register away, and have multiple different files be able to track a single event. Maybe I missundertand that but isn't this missinforming the users/devs as ZOs EVENT_MANAGER events can register multiple functions to the same event too? They are just called after another, by load order of the addons / registered events. As long as the unique identifier passed in is different you can e.g. call EVENT_WHATEVER like 100 times in your same addon. If this isn't the thing the text explains and LibEventHandler does something differently the description of the addon and Wiki should be adopted to explain it better, imo

08/21/20, 07:48 AM

Marazota

Forum posts: 263

File comments: 1526

Uploads: 2

Originally Posted by Baertram

Updated version of the lib with a version check and fix for the initialized events table + some smaller improvements to chat output, and local speed-up variables:
LibEventHandler without LibStub 2.0

Thanks Calamath, I saw your post too late.
Guys, feel free to use Calamath's version as well.
I did not add LibDebuglogger. Both versions are quite the same and should work now properly, even if both would be loaded.

have same error as before, looks like smthing wron but with another addon, not LEH

Code:

user:/AddOns/InventoryAssistant/InventoryAssistant.lua:654: attempt to index a nil value
stack traceback:
user:/AddOns/InventoryAssistant/InventoryAssistant.lua:654: in function 'IA_InventoryAssistant:InitializeSettingsMenu'
|caaaaaa<Locals> self = [table:1]{groupLoots = T, showFCOISGearSetMarkers = T, onlyDuplicates = F, showCrafted = T, onlyMarkedItems = F, onlyLoots = F, onlyNonCP160 = F, showFCOISDynamicMarkers = T, onlyCP160 = F, showNonSetItems = T, showBuyable = T, showMonsterSets = T, showEnchants = T, showItemLevels = T, showBound = T} </Locals>|r
user:/AddOns/InventoryAssistant/InventoryAssistant.lua:502: in function 'eventToFunctionTable'
|caaaaaa<Locals> event = 65536, addonName = "InventoryAssistant" </Locals>|r
user:/AddOns/LibEventHandler/LibEventHandler.lua:21: in function 'CallEventFunctions'
|caaaaaa<Locals> eventCode = 65536, numOfFuncs = 1, i = 1 </Locals>|r

  	Edit/Delete Message

08/18/20, 02:02 AM
Baertram Super Moderator Forum posts: 5177 File comments: 6251 Uploads: 78	Updated version of the lib with a version check and fix for the initialized events table + some smaller improvements to chat output, and local speed-up variables: LibEventHandler without LibStub 2.0 Thanks Calamath, I saw your post too late. Guys, feel free to use Calamath's version as well. I did not add LibDebuglogger. Both versions are quite the same and should work now properly, even if both would be loaded. Last edited by Baertram : 08/18/20 at 02:05 AM.

08/17/20, 10:19 PM

Calamath

Forum posts: 42

File comments: 251

Uploads: 7

Originally Posted by Baertram

LibEventHandler w/o LibStub
Call it via the global variable LibEventHandler instead of using LibStub!

UNTESTED!

I didn't think this library was still used by add-ons other than LorePlay.
I've already provided an updated version in bundles with LorePlay Forever, so I'll be able to update this if needed by other add-ons.

Last edited by Calamath : 08/17/20 at 10:34 PM.

08/17/20, 11:12 AM
Baertram Super Moderator Forum posts: 5177 File comments: 6251 Uploads: 78	LibEventHandler w/o LibStub Call it via the global variable LibEventHandler instead of using LibStub! UNTESTED! Last edited by Baertram : 08/17/20 at 11:16 AM.

05/26/19, 05:03 AM
Marazota Forum posts: 263 File comments: 1526 Uploads: 2	you need add txt file to this addon to allow separate installation and DependsOn

08/13/16, 03:35 PM

Justinon

Forum posts: 8

File comments: 32

Uploads: 2

Originally Posted by Baertram

Hi there,

looks interesting, especially the own events possibility.
But speaking about "code asynchronicity": In your code the asnch calls are delayed using zo_callLater with 500ms, hard coded.
Don't you think this is slowing down everything unnecessarily? I'm not sure how to solve this better but maybe registering an update callback function with EVENT_MANAGER:RegisterForUpdate() and check until some case applies (before 500ms, or after, whatever time it takes. Or maybe fail after a certain "check-time" automatically?!) instead of delaying it fixed a half second.

Baertram

Hey!

Thank you for addressing this point. You're correct; there could be a tiny bit of time in between the calling of the delayed function and the completion of the other function calls, meaning there's some lull time. This could absolutely be the case. The zo_callLater() function actually is just a wrapper around the :RegisterForUpdate() method, simply setting the callback function to be unregistered for update when the initial update is triggered after the passed in time. So by using the zo_callLater() function, I'm already addressing half of what you request. I think now the goal is allowing it to have various times for input.

Therefore, a solution to this is changing the async parameter to be an integer instead of a boolean, allowing for user inputted delay time.

Or perhaps even better, I could just set the delay to be a measly 1ms, so that there's practically no delay, but still achieving the desired effect.

Your thoughts?

EDIT 1: Okay so I just took the best of both worlds; now async can accept and handle both booleans and numbers. If async is set to true, then it'll delay by 1ms, if false it'll fire immediately. Passing in a number will delay it by whatever the number is.

Last edited by Justinon : 08/14/16 at 10:34 PM.

08/12/16, 03:32 AM

Baertram

Super Moderator

Forum posts: 5177

File comments: 6251

Uploads: 78

Originally Posted by Justinon

Originally Posted by Ayantir

Hello Justinon,

What you trying to (re)do is called Hooking.
For Elder Scrolls, this can be done with the function ZO_PreHook() . There is some other variants, but this one covers 99% of the needs.

I'll try to write a litle guide about this, meanwhile, there is already few topics on forums.

If you think something is missing in ESO and you don't find it, it's maybe not that it don't exists, but maybe you didn't searched the good terms or didn't asked to the good people.

Feel free to search/post a topic on the help forum, or ask it on the Gitter channel if you have few questions.
There is some skilled ones hidden here.

Regards,

Hello Ayantir.

While although similar, I think you may be missing the main benefits that this has over what is provided. It's not just about hooking into ESO events; it provides for internally generated events. Sure, you may be able to utilize callback functions when hooking, but it's not as easy to read and nor is it as well structured. My handler is similarly structured to ESO's RegisterForEvent format, allowing for better organization and good design.

My handler doesn't really have much to do with intercepting actions so much as it does providing reactivity to them, although I do see the overlap because they are similar.
Utilizing their hooks can be a mess, and they're used for slightly different purposes.
This makes it easier, simpler, and more manageable than what ESO provides.

So in conclusion, yes, you may be able to do what this library does already standalone. But I'd much rather have it laid out in a concise and familiar format such that code asynchronicity is more apparent and present. It's much more consistent, and that alone makes it worth using

08/11/16, 12:55 PM

Justinon

Forum posts: 8

File comments: 32

Uploads: 2

Originally Posted by Ayantir

08/11/16, 04:45 AM
Ayantir Forum posts: 1019 File comments: 1531 Uploads: 31	Hello Justinon, What you trying to (re)do is called Hooking. For Elder Scrolls, this can be done with the function ZO_PreHook() . There is some other variants, but this one covers 99% of the needs. I'll try to write a litle guide about this, meanwhile, there is already few topics on forums. If you think something is missing in ESO and you don't find it, it's maybe not that it don't exists, but maybe you didn't searched the good terms or didn't asked to the good people. Feel free to search/post a topic on the help forum, or ask it on the Gitter channel if you have few questions. There is some skilled ones hidden here. Regards,

Report this File