ApplicationCommandTarget , using same key to do different things depending on current focus (ctrl-x, for example)

I’m sure I’m missing something simple, but I don’t see how to leverage the ApplicationCommandManager/Target classes to have different behavior for a command depending on context. ie. I want StandardApplicationCommandIDs::del to do different things depending on which window is in focus (as well as be enabled/disabled based on different criteria). My first thought was that I register two ApplicationCommandTargets, which register the same commands/keys, and do the right thing in the perform() function. But that doesn’t seem to work. Am I missing something? The other way I can see to implement it is to have one ACT that handles the command, and somehow manages to know what the current context is, and then chooses to do the correct thing based on that. Any help would be appreciated.

2 Likes

I’ve been looking to do the same, and since the only relevant post on this forum is your unanswered one, I thought I’d ask, did you figure it out “the JUCE way” or did you just roll your own?

Thanks!

I passed the task to another engineer!! lol… I can tell you all about ValueTree’s though! lol

1 Like

The “JUCE way” of handling context-dependant commands is really by updating your command manager and its status (ie: call commandStatusChanged). From here, the set up is fairly simple though tedious to do.

In your subclasses of ApplicationCommandTarget, you’ll have to produce the commands you need in this new context (see getAllCommands), then you’ll need to reset each command as per your new context (in your getCommandInfo, make the result command info active, set its name, change its tooltip, reconfigure the shortcut(s), etc…).

If the flow changes for your commands, as in your targets change, you’ll have to change your first command target and subsequent targets from there.

This is such a typical kind of pattern, where a context is defined by a “screen” concept (where there are modes of operation, which is an extremely popular design strategy for mobile apps), hence why I suggested this feature: FR: Cross-Platform Navigation Controller

3 Likes

Thanks @jrlanglois! I am bookmarking this, because I need to take another stab at implementing this stuff with the information you have shared. oh, and it looks like I already voted for your FR! :slight_smile:

Excellent!

I haven’t a moment to flesh out even a basic example (maybe in a PIP?), where there are a few targets, modes of operation, and some fashion of switching between them and updating the main window/main component. Regardless, I think that’s what’s really needed here seeing that it’s not the first time I’ve noticed some confusion about this system on the forums, even from myself!

2 Likes

Dude, that would be fantastic. I have setup the ApplicationCommandManager before, but I never understood how/when I would update it for each context.