Apache OpenOffice (AOO) Bugzilla – Issue 29181
crash when removing a form control shape from Drawing document
Last modified: 2004-09-17 13:09:11 UTC
* open the attached document * mark the shape * run the macro therein => assertion "presentation object not in list before removal" => GPF The macro removes the control shape in the document, using the UNO API, but obviously Draw doesn't like this :( If you don't mark the object before running the macro, the crash does not happen. It seems the mark list at the view is not properly cleared when removing the object via API. Unfortunately, I need to use this API to fix issue 28502. FS->CL: It would be great if this could be fixed for CWS dba12, since this is where I've planned to fix issue 28502.
Created attachment 15254 [details] document to reproduce the bug case
Created attachment 15255 [details] stack of the crash
Created attachment 15256 [details] stack with the proper mime type
adding "blocking issue 28502"
fixed
verified in CWS dba12 (which is where the blocked bug lingers). Thanks!
closing
I was to fast - reopening :(
Created attachment 15276 [details] extended bug doc
I had to reopen this because: - the fix leads to assertions when grouping controls: Just insert two shapes, mark them both, and group them - this will assert (in all applications) - Though the original crash is fixed, another crash (which I originally was not aware of) remains: Removing, via tha API, a shape which is marked, and part of a shape group, also crashs (because the mark is not removed upon removal). To see the new bug: - open the new bug doc (http://www.openoffice.org/nonav/issues/showattachment.cgi/15276/29181_grouped.sxd) - mark the upper shape (only the shape, not the group) - run the accompanying macro => as soon as the document needs to be redraw, or you hover over it with the mouse, OOo crashes :(
armin, please take over this task since I don't know how to handle the sideeffects in the drawing layer core. Maybe just wait until your selection rework is finished?
AW->CL: This will evtl. take too long. For a quick fix: If SdrMarkView::SFX_NOTIFY(...) gets called on HINT_OBJREMOVED when the object is removed from the model, it would be possible to remove it from the selection there. If Yes, use: void MarkObj(SdrObject* pObj, SdrPageView* pPV, BOOL bUnmark=FALSE, BOOL bImpNoSetMarkHdl=FALSE); from the same view class, iterating over the PageViews (GetPageViewCount(), GetPageViewPvNum(...)) and using bUnmark=TRUE.
Yes Armin I already tried the quick fix but the side effects inside the drawing layer that causes new regressions are out of scope for me. Please fix it in your selection cws
AW: The selection CWS may take too long. I will isolate the selection now (anyways a preparation for selection CWS) and try to secure the selections. That means: The selection will be able to react on object removal (deletion). AW: I will do that in aw013, so that big changes will be in master fast. Resynching this CWS would be a nightmare :-(
AW: Isolation is done. There is a new class, called SdrViewSelection which encapsulates the SdrMarkLists used from the view. Isolation done, preparing making selection more secure.
AW: Thanks to the new DrawHierarchy with the ViewObjectContacts, it is possible to correct the selection actively when that contact is deleted. That's exactly the place where it will be done after selection rework anyways. AW: Checked, works. Done. Now it is safe to call delete () from API.
AW->WG: To check, get the 2nd attachment, load, follow instructions.
.
Fixed.
Verified in CWS.
Tested in master m54. Closed.