Download
(7 Kb)
Download
Updated: 07/30/23 03:33 AM
Compatibility:
base-game patch (9.1.5)
Necrom (9.0.0)
Updated:07/30/23 03:33 AM
Created:08/10/16 11:53 PM
Monthly downloads:1,398
Total downloads:118,659
Favorites:8
MD5:
Categories:Libraries, Developer Utilities
LibEventHandler  Popular! (More than 5000 hits)
Version: 1.3.4
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.
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 (13)
File Name
Version
Size
Uploader
Date
1.3.3
7kB
Calamath
05/20/23 10:01 PM
1.3.2
7kB
Calamath
03/17/23 07:26 PM
1.3.1
7kB
Calamath
10/27/22 09:15 AM
1.3.0
7kB
Calamath
08/22/22 03:04 AM
1.2.99
7kB
Calamath
04/21/22 04:35 AM
1.2.98
7kB
Calamath
02/20/22 04:21 AM
1.2.97
7kB
Calamath
10/08/21 11:59 PM
1.2.96
7kB
Calamath
08/07/21 08:48 PM
1.2.95
7kB
Calamath
05/24/21 09:55 PM
1.2.94
7kB
Calamath
05/19/21 11:21 AM
1.2
5kB
Calamath
05/19/21 11:19 AM
1.1
41kB
Justinon
08/14/16 10:36 PM
1.0
5kB
08/10/16 11:53 PM


Post A Reply Comment Options
Unread 05/19/21, 11:53 AM  
Calamath
AddOn Author - Click to view AddOns

Forum posts: 36
File comments: 216
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:
  1. -- YOUR ADD-ON MANIFEST FILE
  2. -- before
  3. ## OptionalDependsOn: LibEventHandler
  4. libs\LibStub\LibStub.lua
  5. libs\LibEventHandler\LibEventHandler.lua
  6.  
  7. -- after (DELETE ABOVE and REPLACE this one)
  8. ## DependsOn: LibEventHandler

Lua Code:
  1. -- YOUR ADD-ON CODE
  2. -- before
  3. local LEH = LibStub:GetLibrary("LibEventHandler-1.2")
  4.  
  5. -- after
  6. local LEH = LibEventHandler
Last edited by Calamath : 05/19/21 at 09:07 PM.
Report comment to moderator  
Reply With Quote
Unread 08/25/23, 06:42 PM  
Calamath
AddOn Author - Click to view AddOns

Forum posts: 36
File comments: 216
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.
Report comment to moderator  
Reply With Quote
Unread 08/25/23, 12:14 PM  
Baertram
Super Moderator
 
Baertram's Avatar
ESOUI Super Moderator
AddOn Author - Click to view AddOns

Forum posts: 4873
File comments: 5933
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.
Report comment to moderator  
Reply With Quote
Unread 08/25/23, 10:40 AM  
Calamath
AddOn Author - Click to view AddOns

Forum posts: 36
File comments: 216
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.
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.
Report comment to moderator  
Reply With Quote
Unread 08/25/23, 05:07 AM  
Baertram
Super Moderator
 
Baertram's Avatar
ESOUI Super Moderator
AddOn Author - Click to view AddOns

Forum posts: 4873
File comments: 5933
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
Report comment to moderator  
Reply With Quote
Unread 08/21/20, 07:48 AM  
Marazota
AddOn Author - Click to view AddOns

Forum posts: 257
File comments: 1513
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
Report comment to moderator  
Reply With Quote
Unread 08/18/20, 02:02 AM  
Baertram
Super Moderator
 
Baertram's Avatar
ESOUI Super Moderator
AddOn Author - Click to view AddOns

Forum posts: 4873
File comments: 5933
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.
Report comment to moderator  
Reply With Quote
Unread 08/17/20, 10:19 PM  
Calamath
AddOn Author - Click to view AddOns

Forum posts: 36
File comments: 216
Uploads: 7
Originally Posted by Baertram
LibEventHandler w/o LibStub
Call it via the global variable LibEventHandler instead of using LibStub!

UNTESTED!
Hi
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.
Report comment to moderator  
Reply With Quote
Unread 08/17/20, 11:12 AM  
Baertram
Super Moderator
 
Baertram's Avatar
ESOUI Super Moderator
AddOn Author - Click to view AddOns

Forum posts: 4873
File comments: 5933
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.
Report comment to moderator  
Reply With Quote
Unread 05/26/19, 05:03 AM  
Marazota
AddOn Author - Click to view AddOns

Forum posts: 257
File comments: 1513
Uploads: 2
you need add txt file to this addon to allow separate installation
and DependsOn
Report comment to moderator  
Reply With Quote
Unread 08/13/16, 03:35 PM  
Justinon
AddOn Author - Click to view AddOns

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.
Report comment to moderator  
Reply With Quote
Unread 08/12/16, 03:32 AM  
Baertram
Super Moderator
 
Baertram's Avatar
ESOUI Super Moderator
AddOn Author - Click to view AddOns

Forum posts: 4873
File comments: 5933
Uploads: 78
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

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
Report comment to moderator  
Reply With Quote
Unread 08/11/16, 12:55 PM  
Justinon
AddOn Author - Click to view AddOns

Forum posts: 8
File comments: 32
Uploads: 2
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
Report comment to moderator  
Reply With Quote
Unread 08/11/16, 04:45 AM  
Ayantir
 
Ayantir's Avatar
AddOn Author - Click to view AddOns

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 comment to moderator  
Reply With Quote
Post A Reply



Category Jump: