Quote Originally Posted by ZorbaTHut View Post
Quote Originally Posted by Lorandii View Post
Line 78 of LibUnitChange reads
Code:
registered[identifier], lookups[identifier] = Utility.Event.Create("LibUnitChange", identifier .. ".Change")
Aha, you're looking at two different parameters. The first parameter is indeed the identifier of the addon that's creating the event. The second parameter is the actual name of the event. In the case of LibUnitChange, it can generate an arbitrary number of events depending on what it's told to monitor. For example, it might make these calls . . .
Code:
 Utility.Event.Create("LibUnitChange", "player.Change") Utility.Event.Create("LibUnitChange", "mouseover.Change") Utility.Event.Create("LibUnitChange", "player.target.Change") Utility.Event.Create("LibUnitChange", "group04.target.pet.target.owner.target.target.Change")
The only special thing here is that it might generate a ton of different events, one for each thing that is requested. Also, now that I'm thinking about it, LibDataBroker is actually one of those cases where you might want to give it an addon identifier that isn't yours. Conceptually, let's say I write DeathRecorder (it's an addon that records how many times you've died.) It would be *perfectly* reasonable for LibDataBroker to create an event on behalf of DeathRecorder, effectively calling:
Code:
 Utility.Event.Create("DeathRecorder", "Death")
One big advantage of this is that, if DeathRecorder starts spewing out bad events and crashing things that are monitoring its event, then the errors will be properly credited to DeathRecorder and to the addon that's crashing - not to LibDataBroker.
Jump to post...