Order of events fired problem

[remosito]

Howdie all,

I have a problem with Events firing in the wrong order

EVENT_MANAGER:RegisterForEvent(MyAddon.name, EVENT_CLOSE_BANK, function()   d("closing bank") end)
BACKPACK_MENU_BAR_LAYOUT_FRAGMENT:RegisterCallback("StateChange", function(oldState, newState) if newState == SCENE_SHOWN then d("open inventory")  end end)

If I am at banker. and close it then open inventory with i I get the expected

closing bank
open inventory

but if I am at bank and hit i directly I get:

open inventory
closing bank

open inventory gets fired before closign bank...This screws with my add/remove of Keybind bar button(groups) that are in those two functions as well (cut that to make it easier to parse)

To check it's not accross the board. I tested LibFilters Event firing of visible/hidden callback functions I registered there. And those fire in expected order in both cases...

Worst come worst. I can just piggy pack my keybind button stuff onto those libfilter callbacks.

But before I do so and need to make libfilters a required dependency instead of an optional one. I thought I 'd ask if I maybe just picked really unfortunate events to register callbacks to. And there would be better ones that "obey" order....

thanks a bunch in advance

[Baertram]

LibFilters ... And those fire in expected order in both cases...

Yeah as I got the exact same problems like you and have added code to delay the LibFilters fragment callback/or whatver control's OnShow OnHide events I use there, by 1 frame via zo_callLater(function() end, 0) so that the events fire before the fragments callbacks properly...
And this differs from panel/event/fragment to others, and input type (gamepad, keyboard), and usage (keybind, mouse click, etc.).
Took me weeks of testng and fine tuning.

You can use the callbacks of LibFilters if you use the lib. They should fire in the correct order and were added recently to allow addons to just register their code as the callbacks fire, like register your filters and update the inventory of the currently shown panel, unregister older/other anel filters, add your controls to the UI etc.
-> Except: universal deconstruction is not supported yet, working on it some day.

afaik if you press the I to open the inventory it always fires the fragments faster and somehow events like bank, vendor, guild store, close are run later.
Same if you register to the mail keyboard fragment and switch from there to I. Even worse if last opened panel at inventory was the CraftBag! Then you switch from mail -> craftbag directly where some inventory standard funcs do not run and everything is troubled. Even more complex if addons like CraftBag Extended are enabled which provide CraftBag at the mail panel -> press I -> Inventory/ or craftbag (depends what was selecte last there).
And there are multiple other combinations which I was sick of and thus added the callbacks to LibFilters 3.

Allthough I'm not using them everywhere as my LibFilters dependend addons run and work fine like they are (never change a running system :-)) you can use the callback for new addons.
You can test them via the integrated test.xml and test.lua files, you need to uncomment the 2x ## in fro of them in the LibFilters-3.0.txt file and then the test UI is available via /lftestfilters like explained at the LibFilters 3 WIKI at Github.

[Roflbob]

Have you tried to stay exclusively in the lua layer (ie dont mix C-level callbacks and lua-level callbacks). Maybe call RegisterCallback for some bank fragment and use state == SCENE_CLOSING instead of using the C-level RegisterForEvent.

CLOSING should generally be called before SHOWN since one is tirggered at the start of the closing/transition animation and the other is triggered at the end of the show/transition animation.

[Baertram]

Yes, if you stay at the callbacks of fragments or scenes it should be exeuted in order.
But sometimes there is no dedicated fragment and the scene stays the same, so you can try use controls OnEffectivelyShow/OnHide.

[remosito]

thanks a lot for the replies. Was thinking about the C/XML side of things too. Even tried to hunt them down. But wasn't obvious how to find them.. currently using bank_deposit, vendor_sell, fence, launder already. Guild bank deposit might come in the future as well as the "buying" side of all of them....that's a lot of hunting I could spend coding functionality...


Having slept over it. And reading Baertram's experience with the same problem in libfilters.

I think I give it one try of making my Adding/Removing Keybindbar buttons order resistant.



If that doesn't work....libfilters it is....

there is a lot of wisdom in "standing on the shoulders of giants"