+ Reply to Thread
Results 1 to 9 of 9

  Click here to go to the first Rift Team post in this thread.   Thread: API questions

  1. #1
    Champion Lorandii's Avatar
    Join Date
    Jun 2011
    Posts
    516

    Default API questions

    I was reading the documentation for Utility.Event.Create and it confuses me. What part I do understand is the eventTable return, but I don't follow the handle return. Also, isn't the Identifier parameter the same as the Identifier whose code contains Utility.Event.Create? That doesn't appear to be the case in LibUnitChange.

    I am looking at LibUnitChange's code and I get all Or, to ask direct questions: besides some clarification for Utility.Event.Create... I have more or less successfully converted LibDataBroker to Rift (pastebin of code).

    The catch is that the WoW version uses CallbackHandler, which has return values in a specific order. U.E.C. returns a table, so that doesn't matter, but I am missing the handler return.

    Could someone please
    1. Clarify Utility.Event.Create a bit more thoroughly than the official documentation (ie: explain the parameters and return values)
    2. Look at my code and point out how/where I've gone wrong and how to fix what is missing
    As a side question, I have seen the trend in Rift library files, following LibUnitChange's example, of the following
    Code:
    if not Library then Library = {} end
    if not Library.LibUnitChange then Library.LibUnitChange = {} end
    Should I follow suit, or my method acceptable? Would the following work as well?
    Code:
    Library = Library or {}
    Library.LibUnitChange  = Library.LibUnitChange or {}
    Thank you!

  2. #2
    Champion Lorandii's Avatar
    Join Date
    Jun 2011
    Posts
    516

    Default

    Things that go /bump in the night? Just looking for an expanded explanation of U.E.C. and feedback on my opinion question at the end.

    Thanks!

  3.   Click here to go to the next Rift Team post in this thread.   #3
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    Quote Originally Posted by Lorandii View Post
    I was reading the documentation for Utility.Event.Create and it confuses me. What part I do understand is the eventTable return, but I don't follow the handle return. Also, isn't the Identifier parameter the same as the Identifier whose code contains Utility.Event.Create? That doesn't appear to be the case in LibUnitChange.
    The "handle" is a function that you call in order to trigger the event.

    The identifier *can* be the same as the identifier of the addon, but isn't required to be - in some cases, especially with libraries, you may want to credit an event to another running addon.

    That said, I think you may have an old version of LibUnitChange - the new one handles that more elegantly and takes responsibility for the CPU use itself.

  4. #4
    Champion Lorandii's Avatar
    Join Date
    Jun 2011
    Posts
    516

    Default

    Quote Originally Posted by ZorbaTHut View Post
    The "handle" is a function that you call in order to trigger the event.
    Alright, so in my code (just the relevant parts linked), I have two handles: LibDataBroker.domt.__newindex and function LibDataBroker:NewDataObject(name, dataobj)

    Does that mean my code should look like this instead of the first pastebin?
    Quote Originally Posted by ZorbaTHut View Post
    The identifier *can* be the same as the identifier of the addon, but isn't required to be - in some cases, especially with libraries, you may want to credit an event to another running addon.

    That said, I think you may have an old version of LibUnitChange - the new one handles that more elegantly and takes responsibility for the CPU use itself.
    I grabbed LibUnitChange from the ftp site on the first page of the example addons. It says it is version 2.0 and its code is identical to what I was looking at before. Am I missing something?

  5.   Click here to go to the next Rift Team post in this thread.   #5
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    Quote Originally Posted by Lorandii View Post
    Alright, so in my code (just the relevant parts linked), I have two handles: LibDataBroker.domt.__newindex and function LibDataBroker:NewDataObject(name, dataobj)

    Does that mean my code should look like this instead of the first pastebin?
    I'm sort of confused by this code - things like this:

    Code:
    local eventTable[name, object]
    are not, AFAIK, valid.

    In general, you'll need to store the first parameter somewhere, then call it to trigger events. You probably *want* to store the second parameter so you can hand it to someone as an event table, although it can also be found through the Event. hierarchy.

    The actual method you use to do this is entirely up to you - you can even call the same function with the same parameters repeatedly to get the handle and event table again, if you don't feel like storing them. (Not terribly recommended, note, it'd be a bit slow.)

    Quote Originally Posted by Lorandii View Post
    I grabbed LibUnitChange from the ftp site on the first page of the example addons. It says it is version 2.0 and its code is identical to what I was looking at before. Am I missing something?
    I can't find the part where it's passing in an addon identifier besides the addon name. What line are you looking at?

  6. #6
    Champion Lorandii's Avatar
    Join Date
    Jun 2011
    Posts
    516

    Default

    Quote Originally Posted by ZorbaTHut View Post
    I'm sort of confused by this code - things like this:

    Code:
    local eventTable[name, object]
    are not, AFAIK, valid.
    Foiled again! The eventTable variable should probably look like
    Code:
    local eventTable = {name, key, value, self = LibDataBroker.domt.__newindex}
    local eventTable = {name, object}
    Unfortunately, that means I still don't have a handle on the *ahem* handle return.

    Quote Originally Posted by ZorbaTHut View Post
    In general, you'll need to store the first parameter somewhere, then call it to trigger events. You probably *want* to store the second parameter so you can hand it to someone as an event table, although it can also be found through the Event. hierarchy.

    The actual method you use to do this is entirely up to you - you can even call the same function with the same parameters repeatedly to get the handle and event table again, if you don't feel like storing them. (Not terribly recommended, note, it'd be a bit slow.)

    I can't find the part where it's passing in an addon identifier besides the addon name. What line are you looking at?
    Line 78 of LibUnitChange reads
    Code:
    registered[identifier], lookups[identifier] = Utility.Event.Create("LibUnitChange", identifier .. ".Change")

  7.   Click here to go to the next Rift Team post in this thread.   #7
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    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.

  8. #8
    Champion Lorandii's Avatar
    Join Date
    Jun 2011
    Posts
    516

    Default

    Hmm, you are correct. I will change the following lines accordingly.
    Code:
    LibDataBroker:NewDataObject, eventTable = Utility.Event.Create(identifier, identifier.. "ObjectCreated")
    LibDataBroker.domt.__newindex, eventTable = Utility.Event.Create(identifier, identifier.. "AttributeChanged")
    Now it looks better, and might even function. Keep in mind that eventTable is local to each function, and doesn't tread over itself. Do my handles look right? I'd say no, but I can't put my finger on it. They just don't look correct.

    **EDIT: I could add Utility.Dispatch(identifier) to each function. Then for certain the system would think "DeathRecorder" was at fault. Overkill?
    Last edited by Lorandii; 11-18-2011 at 03:59 AM.

  9.   This is the last Rift Team post in this thread.   #9
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    Quote Originally Posted by Lorandii View Post
    Now it looks better, and might even function. Keep in mind that eventTable is local to each function, and doesn't tread over itself. Do my handles look right? I'd say no, but I can't put my finger on it. They just don't look correct.
    Looks right to me. Keep in mind that I'm saying that based on looking at code, not using it. Test extensively

    Quote Originally Posted by Lorandii View Post
    **EDIT: I could add Utility.Dispatch(identifier) to each function. Then for certain the system would think "DeathRecorder" was at fault. Overkill?
    Overkill - if LibDataBroker never creates any frames, and never gets triggered directly by an event, then it will never be credited for any CPU usage or errors. Seriously though, the answer is "try it out and create a bunch of artificial crashes".

+ Reply to Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts