Are TextFrame IDs immutable?

[C330 S]

Can TextFrame IDs change, after the TextFrame has been created?

I have pairs of related TextFrames (in the same document) and want to store the ID of the other frame in a label. This only works, if the IDs don’t ever change.

The API reference describes ID as »The unique ID of the TextFrame«.
Document.id is described the same way (»The unique ID of the Document.«) and these IDs are assigned each time a document is opened.

I did a few tests, and my ID did not change when:

• Adding other PageItems
• Saving, Saving as, Saving as Copy
• Opening a cc22 file in cc24
• Restarting InDesign

However, it did change after exporting to idml (which I can live with).

Alhough it appears that IDs do not change, can anyone actually confirm, that this is the case?
And it would be interesting to know if this also applies to all (?) other IDs.

[davidt12412601]

I don't know about text frame ids, but our workflow depends on page ids, which I can confirm are immutable. As you pointed out, export to idml will change them, but I assume that's because when opening an idml file InDesign is actually importing the idml file and creating a new document from its content.

[rob day]

Hi @C330 S , If you cut and paste a textFrame, the pasted frame would get a new ID.

[davidt12412601]

I suppose that means that object ids truly are immutable, and that a cut/paste operation actually creates a new object then applies certain properties from the original?

[rob day]

The ID property is read only so it can’t be changed or set via scripting. Not sure you could prevent a cut and paste—maybe with a listener?

[Peter Kahrel]

When you move a frame in a document the frame's id doesn't change. You can't move a frame from one document to another, you have to duplicate it. And then its id does change.

[Peter Kahrel]

> If you cut and paste a textFrame, the pasted frame would get a new ID

Yet another reason to avoid cut-and-paste like the plague!

[Peter Kahrel]

> And it would be interesting to know if this also applies to all (?) other IDs.

Yes, that goes for all IDs. 

[C330 S · Accepted solution]

Tanks all for your replies!

by chance I found the following from Harb in this thread:

The ids do not change. They correspond to the UIDs on the C++ level

which is how InDesign keeps track of objects...

So it does seem to be generally accepted that IDs never change.

Unless the object is ›rebuilt‹ in some way. This could be due to:

• Cutting and pasting
• Export to / Import from IDML or IDMS

IDs also do not change, if you change the type of an object (e.g. Oval => TextFrame).

Of course this dosn’t apply to document-IDs (probably also book-IDs).

These are assigned on the fly, each time a document (or book ?) is opened. 

I have tried to summarise everything here, so I will mark this as the accepted answer.
I hope this isn't bad style – I don't want to steal anyone's laurels.

Regards,

Martin

[Manan Joshi]

InDesign document is basically sort of a database and the id's are the primary keys to identify the objects in this database. So if it is the same object the id would not change with any operation. Things like copy paste creates a new object so new ID. IDML export is akin to rebuiliding of the DB from scratch in my opinion so ID's would be changed but could have remained the same as well.

-Manan

[Robert at ID-Tasker]

@C330 S 

Do not store original IDs - use your own IDs stored in the Label - you can of course use original IDs set by InDesign on the first run - then make a list of all objects and their Labels - and pair them at the begining of your script.

I've done it this way when creating online system for catalogues for STANLEY.

First run of my tool would get IDs set by InDesign and set as a label - "mark" them - then on the next run - I woud read all labels & current IDs and pair them for quicker access via .itemByID().

So "my" IDs would be stored in the online database - after first run - and when someone changed text online - I had no problem locating correct object in the current document and update.

[Robert at ID-Tasker]

@C330 S

Then, you can use .insertLabel(key, value) & .extractLabel(key) instead of .label

[C330 S]

@Robert at ID-Tasker, during the developement of my script, this became a theoretical question. 

I switched to identifying the textFrames by their text content.
However, I still find it interesting, to discuss and compare the different approaches. 

If I understand you correctly, you – more or less – store a backup of the original InDesign ID in a label.

If someone were to duplicate such an object, wouldn’t thei duplicate the label as well? 

Then you’d have two identical (label-)IDs.

I’m aware of .insertLabel and extractLabel. I use it to store the coordinates of my objects.

This way I can find out later, if the object has been moved (actual coordinates != stored coordinates).

-- Martin

[Robert at ID-Tasker]

@C330 S

Yes, you'll have two objects with the same custom ID.

If it's "bad" - then it's easy to resolve - duplicated object's ID (*) will be higher than source's ID - in case of user's interaction - but it's not a problem when you are duplicating. 

(*) I'm pretty sure, InDesign isn't re-using freed IDs - just increasing the counter - and as it's Long...

But maybe it's a reason why sometimes files crash - when people do not do Save As with a new name - housekeeping that reassigns IDs - and one of the counters overflows? 

[Robert at ID-Tasker]

(*) I'm pretty sure, InDesign isn't re-using freed IDs - just increasing the counter - and as it's Long...

But maybe it's a reason why sometimes files crash - when people do not do Save As with a new name - housekeeping that reassigns IDs - and one of the counters overflows? 

Anyone have a big document that crashes - for investigation? 

[C330 S]

@Robert at ID-Tasker, I don’t think IDs are reassigned during ›Save As‹.

I tried it (as well as ›Save A Copy‹) and in my case both did keep the ID (singular, as the test document had only one text frame). The only file operation, that produced changed IDs was an export to IDML and reopening the file again. 

To me this makes sense: All ›Save‹-variants do keep an (databaseesque)  InDesign file, while the IDML export is basically a zip with XML files. I couldn’t find an ID in an test-IDML-export.

And I think reassigning IDs during ›Sava As‹ would be pretty complex. So why would Adobe bother?

[Robert at ID-Tasker]

Looks like you are right @C330 S - it looks like Save As isn't changing IDs on Save As:

I thought that "Save As with a new name" would be IDMLing in the background...

[Peter Kahrel]

> I thought that "Save As with a new name" would be IDMLing in the background...

No, it just removes the undo history.