On Thu, 1 Jul 2004, Bob Jamison wrote:

** (inkscape:7718): CRITICAL **: Attempt to set id of bound SPRepr (0x8f98b34) without having registered the SPObject in the document's id table

I know that some code could set the ID of the SPObject, too, but I fear that might break things further.

Yes .. it is possible to cause some serious damage by messing with that.

Just before I lost internet access, I was in the process of adding some checks to Inkscape to verify that we were really maintaining important invariants.

That particular check I added is erroneous; sp_object...change_attr (sorry, from memory) should instead return TRUE without complaint in the case where defid == NULL. (well, perhaps it should complain, but it should certainly permit the operation)

I would have removed it earlier but I cannot commit from home currently (I cannot really spend time on Inkscape at work, and am not generally going to be answering emails).

Note that the two other warnings which I added there, "already bound to another SPObject" ( defid != NULL && defid != object ), and "cannot remove id of bound SPObject" ( newval == NULL ) are legitimate warnings -- they indicate that the code really is doing something bad.

It's probably best to disable the "cannot remove id" warning (but still return FALSE in that case, because the transformation really is fundamentally invalid as long as the SPObject exists) and leave things as they are for the release. Returning FALSE won't actually harm undo.

The "already bound to another SPObject" getting triggered on paste is a little stickier; something very wrong and broken is apparently happening there. We were obviously getting away with it somehow before, and maybe disabling that check just for the release and returning TRUE for that case is the best (least worse) thing to do. But I don't feel good about it.

-mental