Re: Attempt for an UNO Undo API

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 | [email protected]
Oracle Office Productivity: http://www.oracle.com/office