Authors CurseForge

Quote from Nevcairiel

Unregistering in event handlers seems to have changed in 3.3.3 and is now queued until the next frame. So it actually does unregister, just takes until all event handlers are done running.

this seems to also affect registering inside a handler only there's no queue -- it just fails to do it.

probably a rare problem, but it seems that "loadwith" addons load inside of an "ADDON_LOADED" event handler, so it appears they can't register their own ADDON_LOADED events directly.

Quote from Slakah

A safe prehook without using a table:

...

Nice, that definitely seems to make the most sense.

@lilsparky

I wonder if the issue is that the "ADDON_LOADED" event IS being registered, but because of the queue it isn't being registered until after the ADDON_LOADED event has already fired.

Edit:
Also related to weird event 'queuing' behavior.
I'm not exactly sure how the order of events processing is determined. I used to assume it was a simple queue. However, take the following example.

--Addon1.lua - loaded before Addon2
frame1:RegisterEvent("LOOT_OPENED")

frame1:LOOT_OPENED() -- just assume the event handler dispatched the event to this function
    CloseLoot(); -- assume we decided all the loot was garbage, didn't want any of it
end

--Addon2.lua - loaded after Addon1
frame2:RegisterEvent("LOOT_OPENED")
frame2:RegisterEvent("LOOT_CLOSED")

frame2:LOOT_OPENED()
    print("The loot opened!");
end

frame2:LOOT_CLOSED()
    print("The loot closed!");
end

--Expected output when looting if the events were processed in a queue
The loot opened!
The loot closed!

--Actual output
The loot closed!
The loot opened!

For some reason the addons which registered the events after the first process them out of order if they're both fired in the same frame. I'm guessing for some reason the events are processed like a stack rather than a queue, or they're processed in alphabetical order?

@lilsparky

I wonder if the issue is that the "ADDON_LOADED" event IS being registered, but because of the queue it isn't being registered until after the ADDON_LOADED event has already fired.

no, it's actually not even registered. it gets no ADDON_LOADED events (for any other addons that load after it has) and then to make absolutely sure, i had it tell me all the frames registered to ADDON_LOADED -- the frame in question was not listed.

@OrionShock
I understand what you're saying. So it seems that any event triggered from an API call is handled by every addon before that API call returns. o.O I definitely see potential for stack overflow if this effect was chained by multiple addons.

Quote from x87bliss

@OrionShock
I understand what you're saying. So it seems that any event triggered from an API call is handled by every addon before that API call returns. o.O I definitely see potential for stack overflow if this effect was chained by multiple addons.

yeah, i got stack major overflows with my automated trade skill link scanner because i was closing frames in TRADE_SKILL_SHOW events and opening frames in TRADE_SKILL_CLOSE events (causing a feedback loop).

most of the time, a function will essentially be making a direct call to any event handlers registered to that event. i had assumed there was a handler thread running that dispatched things from a root level, so learning this has really helped me understand how it all works.

boy, this also causes problems for trade skill scanning in other ways.

in reaction to TRADE_SKILL_UPDATE, a mod might wish to record info on all trade skills. to be thorough, it's a good idea to make sure headers are expanded and no filtering is taking place. however, making those adjustments triggers a TRADE_SKILL_UPDATE event. to avoid recursion in the scanner, you can unregister the TRADE_SKILL_UPDATE event while resetting your filters, then re-register when done. except, now you can't i guess...?

oh sure, that's what i do anyways for safety (locking). i was just pointing out something i ran across working on some code last night.

Another thing you can do, similar to locks, is make your own Register/Unregister/IsRegistered event functions for your frame. Make the first call to Register actually register the event. Any call to Unregister just raise a flag for your OnEvent handler to not dispatch the message. A subsequent call to Register would clear the flag. Then IsRegistered would return the status of this flag.

This solution is probably only sensible for existing large addons where you don't want to go through each event to manually add locks, and already rely on the UnregisterEvent working.

Quote from Slakah

A safe prehook without using a table:

local OldCollapseSkillHeader = CollapseSkillHeader
local function CollapseSkillHeaderPreHook(arg1, arg2, ...)
	-- do stuff with arg1 and arg2
	return ...
end

function CollapseSkillHeader(arg1, arg2, ...)
	return CollapseSkillHeaderPreHook(arg1, arg2, OldCollapseSkillHeader(arg1, arg2, ...))
end

Coming a bit late in the discussion. Be careful the name you choose because, although the function is called CollapseSkillHeaderPreHook, it's code is executed AFTER the hooked function has returned.

local original_CollapseSkillHeader = _G.CollapseSkillHeader

local function CollapseSkillHeaderPostHook = function (...)
  -- you may here modify the values returned by the call to the original API
  return ...
end

local function CollapseSkillHeaderPreHook = function (...)
  -- you may here modify the values sent to the original API, or choose not to call the API at all
  return CollapseSkillHeaderPostHook(original_CollapseSkillHeader(...))
end

_G.CollapseSkillHeader = CollapseSkillHeaderPreHook

Quote from jerry

Coming a bit late in the discussion. Be careful the name you choose because, although the function is called CollapseSkillHeaderPreHook, it's code is executed AFTER the hooked function has returned.

Yup your right, edited my previous code to avoid confusion.