https://bugs.documentfoundation.org/show_bug.cgi?id=117162
--- Comment #15 from Julien Nabet <serval2...@yahoo.fr> ---
(In reply to Mike Kaganski from comment #14)
> (In reply to Julien Nabet from comment #13)
>
> Then it might make sense to have a copy, but still before each deletion of
> an object in that copy, check if it still exists in the main list. Or
> something like that.
Here is the result of printing at 2 moments maAllIncarnatedObjects, they seem
identical:
$6 = std::__debug::unordered_set with 48 elements = {[0] = 0x9c22b90, [1] =
0x9f7c210, [2] = 0xa5308e0, [3] = 0xa2e3700, [4] = 0x9d2f970, [5] = 0x9e4cb30,
[6] = 0xa2c05e0, [7] = 0x9fece30, [8] = 0x9d67a10,
[9] = 0x9d69930, [10] = 0x9ca3d00, [11] = 0xa7cc460, [12] = 0x579acf0, [13] =
0x5914820, [14] = 0x9d773d0, [15] = 0x9fedbb0, [16] = 0x9cac200, [17] =
0x9c4e8e0, [18] = 0x69e1ae0, [19] = 0x9e4fe90,
[20] = 0x9e35de0, [21] = 0xa8074a0, [22] = 0xa403dc0, [23] = 0xa4ce360, [24]
= 0x9bf4970, [25] = 0xa546670, [26] = 0x9d1aaf0, [27] = 0x9f9ba10, [28] =
0x9cb0370, [29] = 0x5fae0f0, [30] = 0x9d2a7d0,
[31] = 0x9ca6470, [32] = 0x9c32630, [33] = 0x9c3bd60, [34] = 0x9cc5a80, [35]
= 0xa355b90, [36] = 0x9cde0b0, [37] = 0xa570c10, [38] = 0x5ee91f0, [39] =
0xa251b30, [40] = 0x9d32570, [41] = 0x9d372e0,
[42] = 0xa35e340, [43] = 0xa548240, [44] = 0x9d1fa10, [45] = 0xa35b780, [46]
= 0x9ff3490, [47] = 0x9d15030}
$7 = std::__debug::unordered_set with 48 elements = {[0] = 0x9c22b90, [1] =
0x9f7c210, [2] = 0xa5308e0, [3] = 0xa2e3700, [4] = 0x9d2f970, [5] = 0x9e4cb30,
[6] = 0xa2c05e0, [7] = 0x9fece30, [8] = 0x9d67a10,
[9] = 0x9d69930, [10] = 0x9ca3d00, [11] = 0xa7cc460, [12] = 0x579acf0, [13] =
0x5914820, [14] = 0x9d773d0, [15] = 0x9fedbb0, [16] = 0x9cac200, [17] =
0x9c4e8e0, [18] = 0x69e1ae0, [19] = 0x9e4fe90,
[20] = 0x9e35de0, [21] = 0xa8074a0, [22] = 0xa403dc0, [23] = 0xa4ce360, [24]
= 0x9bf4970, [25] = 0xa546670, [26] = 0x9d1aaf0, [27] = 0x9f9ba10, [28] =
0x9cb0370, [29] = 0x5fae0f0, [30] = 0x9d2a7d0,
[31] = 0x9ca6470, [32] = 0x9c32630, [33] = 0x9c3bd60, [34] = 0x9cc5a80, [35]
= 0xa355b90, [36] = 0x9cde0b0, [37] = 0xa570c10, [38] = 0x5ee91f0, [39] =
0xa251b30, [40] = 0x9d32570, [41] = 0x9d372e0,
[42] = 0xa35e340, [43] = 0xa548240, [44] = 0x9d1fa10, [45] = 0xa35b780, [46]
= 0x9ff3490, [47] = 0x9d15030}
About the ownership, I checked it's done at 3 locations:
reportdesign/source/core/sdr/RptObject.cxx:434:
pShape->TakeSdrObjectOwnership();
svx/source/customshapes/EnhancedCustomShapeEngine.cxx:260:
pShape->TakeSdrObjectOwnership();
svx/source/svdraw/svdobj.cxx:2835:
mpSvxShape->TakeSdrObjectOwnership();
Here's the comment in reportdesign/source/core/sdr/RptObject.cxx:
"UNDO in the report designer is implemented at the level of the XShapes, not
at the level of SdrObjects. That is, if an object is removed from the report
design, then this happens by removing the XShape from the UNO DrawPage, and
putting this XShape (resp. the ReportComponent which wraps it) into an UNDO
action.
Unfortunately, the SvxDrawPage implementation usually deletes SdrObjects
which are removed from it, which is deadly for us. To prevent this,
we give the XShape implementation the ownership of the SdrObject, which
ensures the SvxDrawPage won't delete it.
"
Knowing that in svx/source/svdraw/svdobj.cxx, it indicates this:
"// I think this may never happen... But I am not sure enough .-)"
perhaps ownership mechanism needs some cleaning/review/refactoring and there
could be a way to remove TakeSdrObjectOwnership so we could avoid all these
pbs.
--
You are receiving this mail because:
You are the assignee for the bug.
