To obtain a prefix ID range for your plug-in(s), submit a request via the web form at:
InDesign prefix ID registration page.
Issue
For Adobe(R) InDesign(TM) plug-ins that you develop, you'll need a range of unique IDs to use in identifying the plug-ins and their elements. We'll assign you a hexadecimal prefix (for example, 0x42D00) that has 256 possible offsets. This assigned prefix ID range (for example, 0x42D00 through 0x42DFF) does not identify you as a developer, but is only a way for Adobe InDesign to catalog each plug-in and all its associated objects by unique ID numbers.
NOTE: The application requires each plug-in to have an ID (base ID) that is unique with respect to all other plug-ins. Each boss defined by a plug-in must also have an ID that is unique with respect to all other bosses in all other plug-ins. The same is true for interface IDs, implementation IDs, and widget IDs.
Solution
If you need a prefix ID range for your plug-in(s), go to
InDesign prefix ID registration page. You will receive a prefix on a Web page immediately after submitting the form and also by email.
Assign Prefix IDs to a Plug-in
Once you obtain a prefix ID range from Adobe, you can use the associated IDs to identify the elements of your plug-ins. We recommend that you use the prefix itself (for example, 0x42D00) as the plug-in ID, and add an offset from this ID to assign the IDs for bosses, interfaces, etc., within the plug-in. For example, for the prefix 0x42D00, these might be your ID assignments for your first plug-in.
// Plug-in ID
#define kPlugin_1_Prefix RezLong(0x42D00)
DECLARE_PMID(kPlugInIDSpace, kPlugin_1_ID, kPlugin_1_Prefix + 0)
// ClassIDs (bosses)
DECLARE_PMID(kClassIDSpace, kP1Boss1, kPlugin_1_Prefix + 0)
DECLARE_PMID(kClassIDSpace, kP1Boss2, kPlugin_1_Prefix + 1)
.
.
.
DECLARE_PMID(kClassIDSpace, kP1Boss9, kPlugin_1_Prefix + 8)
// Interface IDs
DECLARE_PMID(kInterfaceIDSpace, IID_IP1FIRST, kPlugin_1_Prefix + 0)
DECLARE_PMID(kInterfaceIDSpace, IID_IP1SECOND, kPlugin_1_Prefix + 1)
// Implementation IDs
DECLARE_PMID(kImplementationIDSpace, kP1OneImpl, kPlugin_1_Prefix + 0)
DECLARE_PMID(kImplementationIDSpace, kP1TwoImpl, kPlugin_1_Prefix + 1)
.
.
.
DECLARE_PMID(kImplementationIDSpace, kP1FiveImpl, kPlugin_1_Prefix + 4)
// Widget IDs
DECLARE_PMID(kWidgetIDSpace, kP1MyFirstWidgetID, kPlugin_1_Prefix + 0)
NOTE: Each boss has a unique ID. For example, kP1Boss9 has the ID 0x42D08. The same is true for interfaces, implementations, and widgets. However, note that IDs are not unique across object types. For example, kP1Boss2 has the same ID as IID_IP1SECOND and kP1TwoImpl. This does not cause a clash because Adobe InDesign uses separate catalogs for each type of object and does not compare IDs across object types.
Assign Prefix IDs to Additional Plug-ins
If you have additional plug-ins, you could ask Adobe for other prefix ID ranges, but that would waste unused IDs in the prefix ID range you've already received. In the example above, 0x42D09 through 0x42DFF would be wasted. Instead, we would like you to partition the remainder of the prefix ID range that you've been assigned and use it for additional plug-ins. You will only need to request another range if you run out of IDs.
Here's an example of ID assignments for a second plug-in using an existing prefix ID range. Looking back at the example in the previous section, plug-in 1 uses as its highest ID 0x42D08, leaving the IDs 0x42D09 through 0x42DFF. Let's set up plug-in 2 using a partition of the ID range that starts at 0x42D20 (plug-in ID). This partitioning reserves 23 additional IDs (0x42D09 through 0x42D1F) for future expansion in plug-in 1.
NOTE: Plug-in 2 happens to have fewer bosses and more interfaces, implementations, and widgets than plug-in 1. Note, however, that NONE of the IDs for any object type overlap those for plug-in 1.
// Plug-in ID
#define kPlugin_2_Prefix RezLong(0x42D20)
DECLARE_PMID(kPlugInIDSpace, kPlugIn_2_ID, kPlugin_2_Prefix + 0)
// ClassIDs (bosses)
DECLARE_PMID(kClassIDSpace, kP2Boss1, kPlugin_2_Prefix + 0)
DECLARE_PMID(kClassIDSpace, kP2Boss2, kPlugin_2_Prefix + 1)
.
.
.
DECLARE_PMID(kClassIDSpace, kP2Boss7, kPlugin_2_Prefix + 6)
// Interface IDs
DECLARE_PMID(kInterfaceIDSpace, IID_IP2FIRST, kPlugin_2_Prefix + 0)
DECLARE_PMID(kInterfaceIDSpace, IID_IP2SECOND, kPlugin_2_Prefix + 1)
DECLARE_PMID(kInterfaceIDSpace, IID_IP2THIRD, kPlugin_2_Prefix + 2)
// Implementation IDs
DECLARE_PMID(kImplementationIDSpace, kP2OneImpl, kPlugin_2_Prefix + 0)
DECLARE_PMID(kImplementationIDSpace, kP2TwoImpl, kPlugin_2_Prefix + 1)
.
.
.
DECLARE_PMID(kImplementationIDSpace, kP2ElevenImpl, kPlugin_2_Prefix + 10)
// Widget IDs
DECLARE_PMID(kWidgetIDSpace, kP2MyFirstWidgetID, kPlugin_2_Prefix + 0)
DECLARE_PMID(kWidgetIDSpace, kP2MySecondWidgetID, kPlugin_2_Prefix + 1)
CAUTION: To avoid ID clashes in your plug-ins, be careful about the partitioning of the prefix ID range. In the previous plug-in 2 example, if we had chosen to partition at 0x42D01 instead of 0x42D20, the plug-in IDs for plug-in 1 and plug-in 2 would still be unique, but some of the IDs for the contained objects would overlap and cause clashes. For example, kP2Boss1 would have the same ID as kP1Boss2. Adobe InDesign would show an assert when loading plug-in 2. If we increased the amount of the partition for plug-in 2, the overlap would eventually disappear and both plug-ins would load without asserts.