Originally Posted by Seerah
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.