How reliable are Filters menu commands?

I noticed almost all filter menu and submenus have items with negative command IDs. How reliable is to depend on these in a plugin? AFAIK negative commands might not be consistent between different platforms (Win vs Mac). Also no guarantee command ID won’t change during some Ps update.

Or am I wrong here and can be sure this wouldn’t break in the future if I hardcode the ID?

Negative IDs are not guaranteed to be persistent between Ps versions – and not even between users. I’d use the menu text instead (although you will have to worry about localization, since that text can changes w/ locals)

I see… So basically it’s not really possible to normally use these as buttons :frowning: It’s not worth figuring out all the locales strings and hardcoding them into a plugin. Yet another feature is removed from the list :frowning: Maybe some day…

@kerrishotts, it seems even positive IDs can stop working without any warning…

It used to be 1461 for Select > Subject
After update menu changed and it’s now split into two - on cloud and on device. Totally different IDs and old item now has enabled: false, visible: false. Because it’s not enabled, command ID 1461 just doesn’t work any more.

How do we deal with such changes?

What if you would record “Insert menu item” in actions panel? And then save as .atn file and load into Occultist and send descriptors in Alchemist to generate source code? Maybe you could find some enum or something like that.

As I mentioned in DM, I got the code and this worked for Select > Subject > Cloud

const result = await batchPlay(
      _obj: "selectSubjectService",
      _options: {dialogOptions: "dontDisplay"}
   synchronousExecution: false,
   modalBehavior: "wait"

But I see it’s still not a viable solution for my plugin, where user can choose any menu command to use and save it for later :thinking: This doesn’t prevent issues when menu item is removed out of nowhere :frowning:

I’m now thinking and can’t come up with a reason why would 1461 be replaced with 1466. They both do the same thing. Why 1461 couldn’t be simply moved to a submenu and have a different name?

Sometimes Adobe makes changes I really don’t get :frowning:

And I’m now also thinking, that we can’t rely on names either. In this case it changed too. So basically we can’t make use of the menuBarInfo with a certainty it will work after an update.

@kerrishotts, is there any menu item property we can rely on and would not change on an update? I mean, I know there isn’t now, but maybe there’s another way for us to implement plugin buttons for menu items so they wouldn’t stop working unexpectedly? Jardas solution might work I guess, but going through all the menu items manually and recording actions for each one, is not a solution… :frowning: