![]() |
AceEvent-3.0 tricked into registering non-existent events??
In my addon DynamicCam, the user can create custom situations including lists of events when to check the situation conditions.
If the user enters non-existent events, I want to show them my own error message. So I am using pcall() around RegisterEvent() to catch the errors of non-existent events. This seemed to work quite well. But during the addon startup the event-registering function may be called more than once. It seems that with a second try, the non-existing events are registered! Here is a minimal working example: Lua Code:
Why is the second try not exactly like the first one? If I use RegisterEvent(event) instead of RegisterEvent(event, "EventHandler"), it is like that! |
If nobody has an answer to this strange behaviour of AceEvent-3.0,
maybe someone can tell me how to let my code check itself if an event exists? Thanks! |
When use a frame to register non-existed event, it'd throw an error, that's why the first try failed.
I guess the AceEvents handle it like Lua Code:
So, you can make a version of your own, it's not complicated |
OK, it seems that UnregisterAllEvents() tries to unregister every event that was ever given to RegisterEvent(), regardless of whether it is an existing event or not.
So even when a non-existing event is tried to be registered only once, I get the error when UnregisterAllEvents() is called... So I would really need a way to check if an event is valid before I call RegisterEvent(). |
I found a way to get a list of all events:
Lua Code:
So now I can check my events before I call RegisterEvent() :-) |
AceEvent registers or unregisters Blizzard events; it does not process user-defined events. For that, you want Callbackhandler-1.0.
UnregisterAllEvents iterates through all possible Blizzard events and unregisters them from the frame. It does not matter if an event was actually registered or not. Internally, AceEvent will catch if an event was not registered. Therefore, you do not need to do that. For example, if I write code and never register UNIT_HEALTH, UnregisterAllEvents will still check for UNIT_HEALTH, find it wasn't used, and ignore it. If that isn't exactly the process, the other method AceEvent could be using is storing a table of events that really, truly, were registered on the frame, and iterates that table when you use UnregisterAllEvents. No matter which method is used, you are safe, and won't get errors. |
Quote:
Another even more minimal working example: Lua Code:
Gives me this unregister error: Code:
AceEvent-3.0-4.lua:37: Attempt to unregister unknown event "Nonsense_Event" |
Quote:
Lua Code:
|
Quote:
Lua Code:
My problem was really AceEvent's UnregisterAllEvents() function that tries to unregister non-existing events that were tried to be registered using pcall(). Maybe AceEvent assumes that a script will never continue after its RegisterEvent() fails. So it does not bother to remove a non-existent event from its own table of (putatively) registered events...? |
Quote:
|
Quote:
Lua Code:
|
Cool! Thanks to both of you! :-D
|
The reason NONSENSE_EVENT fires an error has nothing to do with pcall, and everything to do with that not being a Blizzard event. I did say that only Blizzard events are supported.
It sounds like you are letting users enter a string, which could be anything, and attempting to register the string as an event, valid or not. Why would you do that? Putting in some validation code to check if the event is real would be an excellent idea. You could use strfind or strmatch to parse _G and if the event is found, then register the event. That would prevent users from entering FLUFFS_ARE_CUTE, or at least reduce the list to the two events that have FLU*, both of which are valid. |
Quote:
Quote:
|
Quote:
Clearly, AceEvent does not validate events before adding them to the frame's table. As per the thread's title, no, AceEvent is NOT being tricked into registering non-existent events. It is up to the addon author using AceEvent to do the validation, or simply never use events that don't exist. Which is what 99.9999999999% of authors do in their projects. I can see why there is no validation in AceEvent. Considering the ever-increasing quantity of events, that would bloat AceEvent's code for no gain. |
Quote:
Quote:
|
Quote:
I cannot spot any point where it would seem to maintain such a table of registered events. What really puzzles me is why there is the unregister error when I call RegisterEvent() with callback: Lua Code:
But no error message when I do it without callback: Lua Code:
Thanks! Your help is really appreciated. Quote:
![]() |
All times are GMT -6. The time now is 03:37 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI