Quantcast
Download
(41 Kb)
Download
Updated: 08/14/16 10:36 PM
Compatibility:
Shadows of the Hist (2.5)
Updated:08/14/16 10:36 PM
Created:08/10/16 11:53 PM
Monthly downloads:23
Total downloads:207
Favorites:1
MD5:
Categories:Libraries, Developer Utilities
LibEventHandler
Version: 1.1
by: Justinon [More]
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 utilize LibStub, initialize the library, and learn the API methods, check out the LibEventHandler Wiki Page for all you need to know.
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 (1)
File Name
Version
Size
Author
Date
1.0
5kB
Justinon
08/10/16 11:53 PM


Post A Reply Comment Options
Unread 08/13/16, 03:35 PM  
Justinon
AddOn Author - Click to view AddOns

Forum posts: 8
File comments: 21
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
 
Baertram's Avatar
AddOn Author - Click to view AddOns

Forum posts: 1026
File comments: 936
Uploads: 40
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: 21
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: 827
File comments: 1249
Uploads: 30
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,
__________________
Obsessive Compulsive Coder

My little french Guild: Cercle de l'Eveil
Report comment to moderator  
Reply With Quote
Post A Reply



Category Jump: