i have a sk based dkp mod that is fairly intensive when updating a list, about 4+ seconds of total ui lockout on a well used list (for everyone with the mod, in the raid and in guild) so not exactly the best.
i wanted to break it up so that the ui is still usable and i thought i could use coroutines to wrap the calculations in.
to test the process works, i commented out the yield, the list updates properly but there was something odd.
my print statements were showing that the "reminder" trigger i was using, a SendMessage (just before i would have yielded), was running inline, ie i was getting "resume thread" (from the sendmessage function), "yielded", "resumed" when i was expecting a whole bunch of "yielded", "resumed" then a whole bunch of "resume thread"
SendMessage seems to be executing its entire path there and then - there is no queue, its instant / inline. is this normal and ive just not understood ace3 messages? or are they supposed to act like blizzard events?
i did try it with the yield in there and had the sendmessage function call the actual resume function but i ended up with an error that the thread was still active and could not be resumed - which would only happen if the entire SendMessage and its linked function were executed before the yield.
presuming ive misunderstood is there a way to emulate blizzard like events to get that queueing to happen so i can resume after my (and others) code has run?
i dropped the code down to complete basics, no coroutines at all
function ArkDKP.OnEnable( )
ArkDKP.Output( "register" )
ArkDKP:RegisterMessage( "ARKDKP_EVENT_REGENERATE" )
ArkDKP.Output( "call" )
ArkDKP:SendMessage( "ARKDKP_EVENT_REGENERATE", "test" )
ArkDKP.Output( "rest of code" )
end
function ArkDKP:ARKDKP_EVENT_REGENERATE( event, list )
ArkDKP.Output( "ARKDKP_EVENT_REGENERATE( ", list, " )" )
end
the output from the regenerate function, shows up between "call" and "rest of code", not after.
i cant figure out why we'd need RegisterMessage/SendMessage if they just get executed instantly, ie why would we use this instead of just calling the function directly?
Ace3 indeed resolves all message dispatching immediately, before the method returns.
Edit: SendMessage/RegisterMessage is a simple implementation of the Publisher/Subcriber design pattern, where the publisher is not aware of how many and which kind of subscribers are listening. This allows loose coupling between publishers and subscribers.
If you were sure there is only one subscriber and that you wanted message queuing, it was indeed useless.
i wanted to break it up so that the ui is still usable and i thought i could use coroutines to wrap the calculations in.
to test the process works, i commented out the yield, the list updates properly but there was something odd.
my print statements were showing that the "reminder" trigger i was using, a SendMessage (just before i would have yielded), was running inline, ie i was getting "resume thread" (from the sendmessage function), "yielded", "resumed" when i was expecting a whole bunch of "yielded", "resumed" then a whole bunch of "resume thread"
SendMessage seems to be executing its entire path there and then - there is no queue, its instant / inline. is this normal and ive just not understood ace3 messages? or are they supposed to act like blizzard events?
i did try it with the yield in there and had the sendmessage function call the actual resume function but i ended up with an error that the thread was still active and could not be resumed - which would only happen if the entire SendMessage and its linked function were executed before the yield.
presuming ive misunderstood is there a way to emulate blizzard like events to get that queueing to happen so i can resume after my (and others) code has run?
the output from the regenerate function, shows up between "call" and "rest of code", not after.
i cant figure out why we'd need RegisterMessage/SendMessage if they just get executed instantly, ie why would we use this instead of just calling the function directly?
Edit: SendMessage/RegisterMessage is a simple implementation of the Publisher/Subcriber design pattern, where the publisher is not aware of how many and which kind of subscribers are listening. This allows loose coupling between publishers and subscribers.
If you were sure there is only one subscriber and that you wanted message queuing, it was indeed useless.
no problem, ill shift to an OnUpdate function. thanks.