LibEventHandler : Libraries : Elder Scrolls Online AddOns

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 (12)

File Name	Version	Size	Uploader	Date
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: 27 File comments: 179 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/21/20, 07:48 AM

Marazota

Forum posts: 248

File comments: 1486

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: 4542 File comments: 5615 Uploads: 77	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: 27

File comments: 179

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.

08/17/20, 11:12 AM
Baertram Super Moderator Forum posts: 4542 File comments: 5615 Uploads: 77	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: 248 File comments: 1486 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: 4542

File comments: 5615

Uploads: 77

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

08/11/16, 12:55 PM

Justinon

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

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,

Compatibility:	Necrom (9.0.0) Scribes of Fate (8.3.5)
Updated:	05/20/23 10:01 PM
Created:	08/10/16 11:53 PM
Monthly downloads:	4,161
Total downloads:	93,305
Favorites:	7
MD5:
Categories:	Libraries, Developer Utilities