How reliable are Filters menu commands?

Photoshop UXP Plugin API
, ,
1

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?

image
image1032×1054 49.5 KB

2

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)

3

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…

4

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

image
image1025×501 17.5 KB

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?

5

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.

6

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:

7

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:

8

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:

9

It’s been a year. Any insight on this? Was this even considered to be solved somehow? Why would filters have negative command IDs? And what’s the difference with menu IDs? I see filters have positive (or 0) menu IDs (in opposite to plugins, that have not just negative commands, but also negative menus)

10

If you want to solve this then you should explain the problem. What you are trying to achieve and why. In general having a dependency on UI is bad practice and idea. Right now it might be the only option in many cases but later there will be proper ways to do that. Also, custom 3rd party filters should have their own batchPlay support made by 3rd party. This can be done also for ExtendScripts via special comments. UXP support is to be done.

I think you mentioned why it is a problem. Also since it is UI dependent… first you need to force UI update and then data are available or you risk reading old state if you depend on menu enablement. This also makes plugin and Photoshop slower.

11

Exactly. But as you said - currently it’s the only option.

I’m not sure how to explain more clearly, than I already have :frowning: I give an option for user to select (almost) any menu item and assign it to a button. When that button is clicked, that menu item is executed.

What I have currently, is two implementations:

  • If command ID is positive, I assign that ID to a button and later, when button is clicked, I just execute that command
  • If command ID is negative, I assign menu path to a button (e.g. for liquify it would be ['Filters', 'Liquify']) and later, when button is clicked, I try to resolve menu item by searching through menu by titles

With first option it’s more or less OK-ish (even though far from normal)
With second one there are lots of problems and one of them is the Last Filter menu item (the first one in Filters menu), which gets the name of last executed filter, which in turn makes it resolve instead of actual filter.

1 Like
12

damn! not even this road is safe, I honestly don’t know what to think, if they change many of the buttons on the panel they won’t work anymore and all the work done will be lost. all we have to do is use BatchPlay

13

We need more of the DOM in high quality. Some filters are available in DOM. But not all of them.