https://bugs.documentfoundation.org/show_bug.cgi?id=132714
--- Comment #19 from Armin Le Grand <[email protected]> --- I really don't know about what SW is doing there, including all the selection stuff. I can just say that it fails when in SwFEShell::DeleteRow one SwTableBox also being noted in "SwSelBoxes aBoxes;" gets accessed in SwTableBox::GetSttIdx. This seems to have to do with that in SwFEShell::DeleteRow directly calling over ChartView::updateHard() ChartView::impl_updateView gets triggered. That again does trigger from Chart to SW using UNO API SwTableCursor::NewTableSelection() and SwTableCursor::ActualizeSelection. There it seems as if old and new selectin are somehow matched, where old selection seems to have invalid entries (plausible after a row was deleted) I have no idea how that selection may be already updated/deleted in SwFEShell::DeleteRow *before* the call to EndAllActionAndCall() that triggers the chart repaint (and thus the callback from Chart to get the SW selection updated): I tried in SwFEShell::DeleteRow to reset aBoxes (using aBoxes.clear()), but that did not help. I tried to use TableCursorToCursor(), but false == IsTableMode(), so no m_pTableCursor that needs to be deleted (you can see that indeed the selection is removed when right-click to C2 to open the context menu). I tried to use ClearMark(), but it does nothing - there really is no selection anymore before the call to EndAllActionAndCall(). I also tried in ChartView::updateHard() to call impl_updateView with true instead of false. That prevents the crash, but does not update the chart (since it means bCheckLockedCtrler and the controller is locked during that update). So it seems not to be the selection, but *something* is not (yet) updated/in order in SW when Chart calls back to it using UNO API during chart refresh. Maybe the order inside EndAllActionAndCall should be checked... -- You are receiving this mail because: You are the assignee for the bug.
