ApplicationCommandManager and targets


#1

The documentation says:

When a command is invoked, the ApplicationCommandManager will try to choose the best ApplicationCommandTarget to receive the specified command. To do this it will use the current keyboard focus to see which component might be interested, and will search the component hierarchy for those that also implement the ApplicationCommandTarget interface. If an ApplicationCommandTarget isn’t interested in the command that is being invoked, then the next one in line will be tried (see the ApplicationCommandTarget::getNextCommandTarget() method), and so on until ApplicationCommandTarget::getNextCommandTarget() returns nullptr. At this point if the command still hasn’t been performed, it will be passed to the current JUCEApplication object (which is itself an ApplicationCommandTarget).

To exert some custom control over which ApplicationCommandTarget is chosen to invoke a command, you can override the ApplicationCommandManager::getFirstCommandTarget() method and choose the object yourself.

Maybe I’m being a muppet. But I don’t really understand what this means.

In particular:

To do this it will use the current keyboard focus to see which component might be interested, and will search the component hierarchy for those that also implement the ApplicationCommandTarget interface.

Does it select the component with keyboard focus AND also search the component hierarchy?

Does it only select ApplicationCommandTargets that implement the particular command ID, or does it just hit the first component that implements the ApplicationCommandTarget and then revert to calling via getNextCommandTarget?

If I have a parent (A) and child (B) which both implement ApplicationCommandTarget and a toolbar which is a child of A. When the user clicks on the toolbar will B or A be the default target, and should A have a getNextCommandTarget that points to B or vice versa?


#2

(I was trying to step through this in the debugger and answer the question myself but because the thing triggers everytime focus is changed it’s a bit tricky!)


#3

I think I’m fixing this up with a setFirstCommandTarget(…) and a deterministic chain of getNextCommandTarget’s …but I’m still wondering if there wasn’t some automatic magic I should be relying on here…?


#4

DBGs are your friends in such circumstances!