• 0

    posted a message on CallbackHandler-1.0.lua (callback invocation order)
    Quote from sylvanaar
    You cant guarantee events will arrive in any specific order, unless you could control all the code that was running - and you cant.

    You also have no way of tracking event uniqueness - its especially annoying if you have registered for the same event more than once, or you can receive it more than once each time its fired (or both!)


    I did not make any assumption on the order the events are generated by the system, and I am not concerned with it.

    Regarding event uniqueness, are you saying that the system can generate multiple copies of the very same event?
    Posted in: Ace3
  • 0

    posted a message on Skada: a damage meter
    I have seen that you start the combat only if some damage is done.
    If you want a semantic similar to (a supposedly existent) UNIT_ENTERED_COMBAT, shouldn't you consider also misses and the nature of the target?

    My 2 yens
    Posted in: General AddOns
  • 0

    posted a message on CallbackHandler-1.0.lua (callback invocation order)
    True. Registering and unregistering events would change the invocation order.
    In my scenario, addon A registers its events and never unregisters them (example: a cache that needs to be invalidated upon some events).

    For me, the topic is closed.
    Thanks.
    Posted in: Ace3
  • 0

    posted a message on CallbackHandler-1.0.lua (callback invocation order)
    I am concerned in the way AceEvent (that uses CallbackHandler) dispatches an event to the listeners that have registered to that event. Guaranteeing a First-Registered-First-Notified (FRFN) invocation order, it is possible to achieve better decoupling.

    For instance, suppose addon B uses addon A.

    A exports some functions whose results, when invoked, depend on the internal state of A, and this state changes in response to some system events.

    Because B depends on A, A is loaded and initialized before B and, hence, its event listeners are registered before the, eventual, event listeners of B.
    If the FRFN invocation order is guaranteed, I can trust that invoking A's functions from inside some B's event listener will always get proper results.
    Moreover, in this way, B does not need to know which events A cares about.

    I hope this will clarify things a bit.

    PS: I am pretty new to the world of wow addons, so it might be possible that I have misunderstood some of the subtleties of their development.
    Posted in: Ace3
  • 0

    posted a message on CallbackHandler-1.0.lua (callback invocation order)
    Are there any test cases for CH (unit testing)?
    I have made some changes so that it now invokes events in registration order (and a little slower than the vanilla version) and I would like to test it more exhaustively than what I have already done.

    Regards
    Posted in: Ace3
  • 0

    posted a message on CallbackHandler-1.0.lua (callback invocation order)
    I know, but using AceHook sounds like shooting a fly with a cannon.
    Anyway, thanks.
    Posted in: Ace3
  • 0

    posted a message on CallbackHandler-1.0.lua (callback invocation order)
    Hum, thank you.
    Posted in: Ace3
  • 0

    posted a message on CallbackHandler-1.0.lua (callback invocation order)
    Hello,

    from the code I guess the events are not fired in registration order, that is, even if addon A registered the event E before B, B may receive E before A.

    Is there any plan of having the dispatcher firing the events respecting the registration order? or

    did blizzard change the behavior of "next"?

    regards
    Posted in: Ace3
  • 0

    posted a message on PitBull 2.0
    Quote from Lyn »

    is there a way to add vertical spacing for buffs, not just horizontal? cause that looks fugly with just horizontal :<


    At present the only thing you can do is to modify the Layout.lua file in the Aura subdir of Pitbull.
    These are the changes I made. I hope they might be of help.

    120c120
    < 				x, y = 0, y + buffsize * (split and 1 or grow)
    ---
    > 				x, y = 0, y + (spacing + buffsize) * (split and 1 or grow)
    150c150
    < 					x, y = 0, y + debuffsize
    ---
    > 					x, y = 0, y + debuffsize + spacing
    210c210
    < 				x, y = 0, y + (invert and -1 or 1) * debuffsize * grow
    ---
    > 				x, y = 0, y + (invert and -1 or 1) * (debuffsize + spacing) * grow
    Posted in: Unit Frames
  • To post a comment, please or register a new account.