Is the menu command ID global?

[Michael_Müller-Hillebrand]

Dear colleagues,

the documentation describes how to add menus and commands and always uses command IDs 1, 2, 3...

nMenu1.DefineAndAddCommand(1,"cmd1","command1","");

nMenu2.DefineAndAddCommand(2,"cmd2","command2","");

function Command(cmd) {

switch (cmd) {

     case 1: alert("Command 1 executed"); break;

     case 2: alert("some other message"); break;

  }

}

To me it seems the command IDs should be unique throughout the session. If so, how can we easily create unique IDs?

- Michael

[Michael_Müller-Hillebrand]

OK, the documentation says:

The value must be unique for each command in your client, but need not be unique for different clients.

As far as I understand, the ExtendScript support is a single client, so if I have scripts from multiple sources that all install menu commands I have to make sure they do not overlap. Or so it seems. It is easier with FDK, as every DLL is a separate client…

I am thinking of a global numbering scheme…

- Michael

[Guest]

One thing I've found is that the cmd value used when defining a new Command does not necessarily match the CommandNum property Frame assigns to the object, dispite what the documentation says. So, it seems that maintaining unique values is handled automatically, though not flawlessly--a complication I've run into though is that defining additional commands seems to override earlier definitions. So, if I add a custom menu during a start-up script, then try to add another command to that menu later on (using a new, different cmd value), the original menu commands no longer function--as if the new Command(cmd) function simply replaces the earlier one.

[Guest]

After further testing, I'll condition my last post. The behavior I observed yesterday (FM forgetting older defined commands when new ones are added) has not been consistent, and I'm not sure what I've done differently.

It definitely happens if you reuse cmd values, but I haven't been able to reproduce the effect I saw yesterday, where different values were causing the same problem.