(IDCS4Win) Strange and befuddling asserts when loading a document

[JADarnell]

I am getting two strange and befuddling asserts when I am loading/manipulating a particular CS4 document.  This first one comes up once or twice when reading the document:

XferReference of invalid UID(30213) detected while reading.  Has the UID been deleted, or is it uninitialized?

I receive the second assert literally dozens of times while loading the document:

UIDCheckStream has detected an invalid reference.  It is safe to continue.

Does anyone have information on what these asserts are trying to tell me?

I am assuming that what they are telling me is that I have empty or corrupt UIDs in the document database.  Is there any way to fix these problems?

TIA,

John

[Dirk Becker]

The first assert means that some object points to a different object while the latter has been deleted.

For example, there is a page item, you removed a color and the color is still in use by the page item's stroke. Class names are for illustration purpose only, could be anything else.

The debug build iterates the whole document database to find such dangling UIDs. It opens every persistent interface and streams it thru a special PMStream to verify the existence of touched UIDs. The stream itself issues that assert, while it is called from within the ReadWrite method of the interface in question.

To solve the problem you have to find out which object is holding that reference, and guess from that the class of the deleted object (e.g. the color), because that class is not available any more for deleted objects. The only thing sure is that the deleted object is not owned / parented by the other one, otherwise the assert would be about XferObject.

How woudl you find the referring class? On a Mac, examine the stack backtrace to see wich ReadWrite is active. On Windows you probably won't have anything readable on the stack. Maybe you can export to IDML, unzip the package and use text search? Of course that assumes your reference is thru something scriptable. Otherwise IDML might at least be a way to repair the document ...

Then you have to find out the way the object was deleted, how that delete command notifies and how you can handle such references - e.g. substitute with a different color, or just clear the reference.

The way to do this depends on object type - color consumers have to register with a weird reference handling service that I still haven't fully understood, page items notify globally via PageItemUtils / kDocBoss subject, others go thru responders, and so forth.

Dirk

[JADarnell]

Dirk:

I wanted you (and the forum) to know the solution I finally settled on.

First of all, these were pages sent in by our customers, most of whom are teenagers, and they are really creative at figuring out how to torture an InDesign document (we publish yearbooksif you don't know what they are, they are traditional, annual publications put out by high schools which hold pictures and other metaphorical bric-a-brac from the school year just finishing upif you do know what they are, then I apologize. Anyway, the schools build the pages, we print them).

What I finally had to do was insert this piece of code wherever I used a color UID:

If(db -> IsValidUID(ColorUID))

Do whatever is involved with the ColorUID;

This resolved the problem of the crashing program. I probably should have also added a db -> DeleteUID() whenever I found an invalid UID but, alas, I did not think of doing so until after the code was on the floor (that is, used by our production people).

Anyway, believe it or not, your input helped me figure out this not so mysterious answer to my dilemma. Thanks for your help.

R,

John

[Dirk Becker]

John,

if these deleted color UIDs are held by your own entities (page items, attributes, your added interfaces etc.), then you have to provide an kRIDXNotifierService, see IRIDXNotifierHandler for details. The colors are lost when a color is deleted, in that case it is supposed to be substituted by a different color. If the color is stored by someone else, please report a bug.

IID_IK2SERVICEPROVIDER,kRIDXNotifierServiceProviderImpl,

IID_IRIDXNOTIFIERHANDLER,...

Checking for IsValidUID is probably ok if your UID is stored with an optional persistent interface (IgnoreTags ...), but in that case you should clean up within your plugin's IPlugIn::FixUpData() method.

DeleteUID() would be the opposite of what you want, the color already has been deleted and you should anyway call that method only from within a command.

Along the last paragraph of my last question I had hoped to learn some more details on that RIDX topic during the summit, but unfortunately the event had other priorities ...

Dirk

[Steven__]

Dirk Becker wrote:

Along the last paragraph of my last question I had hoped to learn some more details on that RIDX topic during the summit, but unfortunately the event had other priorities ...

Did you find out more about targetserver?

[Dirk Becker]

Steven,

targetserver got roughly the same answer as the selection suite filter idea - the responsible developer has already left. At least there should be a working example in the SDK - I have not yet revisited it though.

Dirk