Comment 41 for bug 949997

I'm suspicious of the: svdundo.cxx /SdrUndoInsertObj::Undo/ method - I imagine it is removing a different object than the one it is intended to do (which explains why the main text box in the body disappears, instead of the header on undo ;-) - an off-by-one as it were. With this debugging patch:

--- a/svx/source/svdraw/svdundo.cxx
+++ b/svx/source/svdraw/svdundo.cxx
@@ -759,17 +759,17 @@ void SdrUndoInsertObj::Undo()
     // Trigger PageChangeCall
     ImpShowPageOfThisObject();

- DBG_ASSERT(pObj->IsInserted(),"UndoInsertObj: pObj is not inserted.");
     if (pObj->IsInserted())
     {
         ImplUnmarkObject( pObj );

-#ifdef DBG_UTIL
         SdrObject* pChkObj=
-#endif
         pObjList->RemoveObject(nOrdNum);
- DBG_ASSERT(pChkObj==pObj,"UndoInsertObj: RemoveObjNum!=pObj");
- }
+
+ fprintf (stderr, "UndoInsertObj: RemoveObjNum %p == pObj %p ordinal %d vs %d\n",
+ pChkObj, pObj, (int)nOrdNum, (int)pObj->GetOrdNum());
+ } else
+ fprintf (stderr, "not inserted !\n");
 }

 void SdrUndoInsertObj::Redo()

I get:

UndoInsertObj: RemoveObjNum 0x969d9d8 == pObj 0x9d47390 ordinal 2 vs 0

Which explains the bad behaviour.

Quite -how- this undo list is supposed to keep it's nOrdNum synchronised with whatever is going on in the sdpage is -totally- opaque to me; the whole thing looks crazy from a lifecycle perspective.

It's deeply unclear to me that all this referencing by ordinal is at all sensible - particularly vs. having a reference-counted object handle to an immutable object.

It'd be great to have a translation of GetOrdNum vs. GetOrdNumDirect in svx/inc/svx/svdobj.hxx - to try to grok what's going on there - if there is a German speaker around.