context about action_handler_t
IDA provides multiple features and APIs to extend and enhance it's usability, one of those features is the creation of user defined action_handler_t
objects by inheriting idaapi.action_handler_t
in IDAPython.
The feature involves several APIs, but one of the requirements is having a class that inherits said idaapi.action_handler_t
class and implements two methods. One of those methods is update(self, ctx)
(the other being activate(self, ctx)
).
During an IDA application's lifetime, the update
method will be called multiple times on certain events (startup, a new IDB being loaded, focus shifts to another form, etc). Updates then communicates back wether the action should be enabled or disabled and when to query again by issuing another call to update
.
One of those events is an action's activation
call returns. The motivation is that actions performed as a result of an action being activated might potentially change the state of that same action or other actions.
actual question
While using IDA and certain Qt signals/slots abilities, I've created an activation
method that returns immediately and schedules most of its login to other slots, and I'm now losing the "post-activation" update
call that makes actions respond to overall state changes and change their own state (from disabled to enabled and vise versa).
My question is, how can I force an update
call by IDA's kernel to all existing actions so that when my delayed code finishes it could manually tell IDA it should call update
for all actions to query for their new state?