Hi Malte, > It seems that the idea is that any extension could put it's own Undo > actions in some others UndoManager. > > But what if the Extension terminates (no crash, but by intention), while > I still work with the document? > The Undo actions could have pointers to some data which doesn't exist > anymore, and the extension can't remove the actions from the > UndoManager. Avoiding pointers could mean making the Undo actions more > "expensive" (memory, time). For example, Writer and EditEngine simply > keep Paragraph* when paragraphs ar
Since we're talking about UNO implementations here, there's no such thing as "pointers", only "references". So, the code triggering the Undo/Redo should be prepared for DisposedExceptions, at least. > Last but not least: When one common API for Undo should be used > everywhere longterm, it needs to have support for Repeat (which then can > lead to other funny situations, when some primary undo actions don't > have repeat support, while the according hidden actions have...) At the moment, I don't aim for using one UNDO-API everywhere. In fact, I am convinced that the new UNO API, for now (!), should be a wrapper around existing non-UNO implementations, instead of the other way 'round. Everything else would, so I think, need tremendous efforts. So, I prefer an incremental solution. Which is why I introduced the API here - to gather feedback on how future-proof the design is considered by others. Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
