Quantcast
WoWInterface - View Single Post - [AceAddon-3.0] Module doesn't fire OnEnable/OnDisable function
View Single Post
12-31-17, 07:08 PM   #7
Layback_
An Onyxian Warder
Join Date: Feb 2016
Posts: 356
Hi myrroddin,

Originally Posted by myrroddin View Post
I see you are comparing TukUI/ElvUI code with Ace3 and the game's built-in Lua. No wonder you are confused!
No, I quit having a look at TukUI/ElvUI codes since many addon authors (including you) advised me that those are not a good example for beginners to work with

The current structure of the code is just the way I'm used to at this stage, haha!

Originally Posted by myrroddin View Post
Calling the event handler in OnInit does nothing because you haven't registered the event yet. That is done in OnEnable (correct). If you need it right away, then register the event in OnEnable and then call it in OnEnable. Of course that requires the module to be enabled.
I am not sure if I am understanding correctly, but you mean that the events are registered on OnEnable phase of the AceAddon?

Hm... I guess in my case it's more likely calling a function (event handler in this case) E:ACTIVE_TALENT_GROUP_CHANGED, manually, and that's why I'm passing another paramter called isOnInitialize on its call. Thus, I don't need an event to be registered at this point, but just need that event handler to be called manually

Originally Posted by myrroddin View Post
Outlaw.lua's lines 36-38 are useless because AceEvent already handles that. Either pick AceEvent or handle event script handles yourself; don't mix them.
I've been told that AceEvent can still control those unit specific events, but can't specify which unit it should listen to (e.g. UNIT_AURA). Of course, I could still use AceEvent and put an if statement to check if the unit that is being passed is what I want, but eeh.....

I don't know how the registered events with :RegisterUnitEvent works internally (guess it's done by C, maybe?), but I honestly didn't want it to call function over and over again on my side just for single line of if statement to check if the unit is player or not when there is an update with aura especially while I'm in huge raid.

In addition to that my first intention of handling events separately for AceAddon and its module (module's core frame in this case) was to give them an independent job.

Addon will only use ACTIVE_TALENT_GROUP_CHANGED event for toggling its modules depending on player's current specialization while Outlaw module will use it to show/hide its child objects depending on its talent change (not spec).

Again, you are right that mixing AceEvent and separate event handler would be a bad idea and maybe I should consider combining them into one, but I would like to keep them as they are, at least for now.

I really appreciate your advice!

Originally Posted by myrroddin View Post
There might be a reason why you have holder hooking events, but wouldn't it be easier to just register directly on M?
Same reason as above

Originally Posted by myrroddin View Post
For your last question, if you set the default state to disabled, then yes, OnEnable, OnDisable do not run, and I don't think OnInit even fires (but I'm not 100% certain of that).
Maybe I should do some further experiment regarding this!

Originally Posted by myrroddin View Post
If you want to see a working code base for how to handle Ace3 modules and events, check out SmartRes2 and SmartRes2_Chat. Both work, although I haven't continued them in quite some time. You will notice I do not follow the Tuk/Elv methodology because that is just too complicated and hard to bug fix. You can find both addons here on Wowinterface and also on Twitch/Curse.
Of course I had a look at SmartRes2 and SmartRes2_Chat.

You've already told me to do so when I got confused with AceDB

But guess it is a great idea to revisit those codes for refresh
  Reply With Quote