https://issues.apache.org/ooo/show_bug.cgi?id=120015
--- Comment #4 from Armin Le Grand <[email protected]> --- ALG: I investigated, none of the actions on the opened styles dialog (F11) creates any undo/redo actions, this is missing implementation functionality and too much to create now for this fix. I saw that SdrUndoAttrObj which is used to protocol SfxItemSet changes to SdrObjects uses SfxStyleSheet* to remember the used StyleSheets. One possibility would be to use the Strings Sheet.GetName(), GetFamily() to remember the Style instead and do a SfxStyleSheetBasePool::Find(..) on Undo/Redo to detect if the style still exists. The default style could then be used. This still allows no true undo functionality, settng the default style is not correct. Interestingly SfxStyleSheet is derived from SfxStyleSheetBase and that is derived from comphelper::OWeakTypeObject, thus refcounted. It is possible to use rtl::Reference< SfxStyleSheetBase > mxUndoStyleSheet; instead of SfxStyleSheet* pUndoStyleSheet; This allows to survive the removal of the StyleSheet from the StyleSheetPool. When undoing/redoing code is needed to check if it still is in the pool, add it if not and use it. This allows full undo/redo even with removed StyleSheets; on undo a deleted StyleSheet is re-inserted to the StyleSheetPool, on redo it will stay there as if deletion did not happen. This is acceptable due to the fact that StyleSheet removal has no undo itself and that it will be removed anyways with the next save/load cycle (AFAIK only used StyleSheets survive, but not sure right now). I will add the code so far as patch. It still triggers one assertion (not find parent), but parent works and is set. I'm pretty sure the assertion is wrong. -- You are receiving this mail because: You are the assignee for the bug.
