Advice on Future-Proofing Activate Application Actions?

For the past week I've been revising and expanding a very large set of workflow macros I use. Today, while working on them, I'm struck by just how many "Activate Adobe Audition 2020," "Activate Adobe Media Encoder 2020," "Activate Photoshop 2020," and so on actions are littered throughout all my macros. Every year, I have to go through and manually change all of those to the next year-numbered version of Adobe applications--and other applications whose application titles include version numbers.

I found this thread, Store currently active application in a variable? , and I'm considering that approach. For long macros or many macros strung together into a workflow, which is where I typically call Audition, Media Encoder, Photoshop, Illustrator, and so on, I'm thinking of adding a step that sets variables to the versions of the apps I'm using, and then simply change all of my Activate Application actions to go to the value of the variable... somehow; I haven't figure that part out yet.

Before I invest all that time and effort, though, I was wondering if anyone has any advice or suggestion of a better method.

To get round this you can use two actions as shown here:

2020-09-12_23-15-57

  1. Set a global variable to the name of the app that will be changing over time. I suggest you put this and other similar actions in a single macro that you run every time an app name changes.

  2. In any macro that you need to activate the app, use an action like this.

This approach lets you keep the app names that change over time in a single place that you can easily find and keep updated. The actual macros that use these changing app names (by using action 2) never need to be updated.

I've never had to use this approach myself but with limited testing it seems to work.

YMMV.

3 Likes

@iampariah, I think @tiffle has an excellent idea. I've not used it, nor tested it, but I don't see any reason this should not work.

I would add a small suggestion that you use a naming convention something like this:
DND_CAN__<AppName>

where

  • "DND" means "Do Not Delete"
  • "CAN" means "Current App Name"
  • "<AppName>" is replaced by your generic app name

So for example: DND_CAN__Audition

image

However, I can't find the Action the @tiffle showed above:

image

But I think you could use this Action:
Use Variable action

image

1 Like

Looks like this may be this custom Plugin:
Activate Application by Name String

It was posted in 2015, so you would want to make sure it still works.

@peternlewis, can you comment on which is best to use: This Plugin, or the Use Variable action?

Using a native action would pretty much always be a better solution than a plugin action if the native action does what you want.

I’d forgotten that the action I recommended was a plug-in and wondered why I would do that rather than use a native action. I realise the answer is that the plugin action gives additional options regarding windows etc that the native action doesn’t. @iampariah may want to consider this when implementing a solution.

3 Likes

Good point.

Thanks, guys. I kind of figured that was the best method, but I wanted to see if anyone had a different idea.

@tiffle Thank you for pointing me to that plugin. That makes things cleaner.

1 Like

This is a great little Action and I'm now using it for the same thing @iampariah wanted - i.e. helping deal with the fact Adobe change the whole App name when they bring out incremental versions of their CC Apps - so, "Adobe Illustrator 2019" becomes "Adobe Illustrator 2020" etc.

It made me think though just how annoying it is that Adobe do this and I'm very glad other Apps don't constantly change their names. "Final Cut Pro X" stays "Final Cut Pro X" no matter what incremental version as does "Pages".

One of the joys of using the Mac is how consistent the interface and menu options are across multiple Apps (gong right back to the earliest days of the Mac) so it is slightly irritating when some Apps break these conventions.

2 Likes