2 Replies Latest reply on Feb 2, 2015 9:01 AM by nvkzNemo

    Where can we find a list of keys available in ActionDescriptor?

    fabianf92607302 Level 1

      Where can we find a list of keys available in ActionDescriptor?Where can we find a list of keys available in ActionDescriptor?

        • 1. Re: Where can we find a list of keys available in ActionDescriptor?
          xbytor2 Level 4

          The keys for a particular ActionDescriptor can be determined by ActionDescriptor.getKey(), and the number of keys are determined by ActionDescriptor.count.

           

          A complete list of all keys is not available anywhere that I know of, mostly because they even though the majority are in the PS app, others can be found in in

          dynamically loaded libs, plugins, and in the Bridge app.

           

          For the PS app keys, you can find them in header files for the binary/C header files in the dev kit.

          I've taken the time to consolidate these keys in xtools/xlib/PSConstants.js. The header files that I use are:

          PIStringTerminology.h, PITerminology.h, and PI3d.h.

           

          The ids look like this:

          PSClass._add("Color", "Clr ");

          PSEnum._add("Right", "Rght");

          PSEvent._add("Hide", "Hd  ");

          PSForm._add("Class", "Clss");

          PSKey._add("VersionMinor", "VrsN");

          PSType._add("AlignDistributeSelector", "ADSt");

          PSUnit._add("Pixels", "#Pxl");

           

          The first value is the human readable form while the second value is the 4 char value you pass to app.charIDToTypeID() to get a key.

           

          String IDs look like

          PSString._add("32BitPreviewOptions");

          or

          PSString._add("3DSetGlobalAmbient", "set3DGlobalAmbient");

           

          In the first case, the string is passed to stringIDToTypeID(), while the second case the first value is the human readable string

          and the second is what you would pass to stringIDToTypeID(). The reason for the second case is that Adobe normalizes/standardizes

          the name of stringID used in the dev kit API (over time) while maintaining the preexisting TypeID to maintain backwards compatibility.