Quantcast
ESOUI - View Single Post - Updating stuff on the Wiki
View Single Post
04/14/14, 12:16 PM   #18
Iyanga
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 185
Originally Posted by Seerah View Post
The RegisterForEvent method on EVENT_MANAGER works like this.
Addon A wants me to watch for event B and call function C when event B fires.
Event B fired! I will now send confirmation to Addon A that it was event B that fired, along with all returns from event B that the addon would be looking for.
eventFired = eventCodeB
eventReturns = ...
functionC(eventFired, ...)
That's what I've written exactly before:

function obj.myfunc(param1, param2)
return obj.myfunc2(param3, param1, param2)
end

Including the fact that it doesn't matter how param3 makes it way into the argument list - it is there.


The reason WHY the event handler (RegisterForEvent) passes along the event code is this:
So you can have the same function as handler for different events. It's pretty easy without a large example.

This does not make the eventCode part of the the returns list for the event.
Of course it does. Who else does decide which arguments an callback gets, if not the event handler? I'm not the one deciding it, when I'm registering the handler obviously, I can't tell the event handler what I want. So the event handler does decide it. So the event code is no different than every other parameter. And the description how a callback function for an event has to look like must (for me obviously) equal the way the event handler _does_ call the function.


The event handler takes the event code and prepends it on to the list of returns from the event before sending that along to the function.
So the event code is part of the arguments for the function that is called and previously registered. What I said. The event handler might also decide to remove or nil arguments.


I guess we have to agree to disagree.
  Reply With Quote