SF is up again. Baically the order of undo actions is wrong, and some actions may be lost, when text nodes are edited (no matter whether it's
done
by text tool or by XML editor).
As I've already commented, the problem is that there is no unified undo layer for repr actions and other things (like text cursor movement).
The Repr transaction logging layer is fine as it is -- the thing is that we need undo records at the SPDocument layer that can hold more than just Repr transaction logs.
I may be misunderstanding you. What you say may be correct, but it does not apply to this bug as far as I can tell. What needs to be logged here is nothing but a repr change, namely a change in the content of the text node inside tspan. This is what is broken. The fact that undo does not know about cursor movements is irrelevant - it must simply restore the previous content of the node, and that's what it cannot do properly. The fact that the behavior is the same no matter whether you edit the text node by the text tool or directly in the XML editor proves that the text tool is not the problem, the problem is inside the undo system.
I do have a rough sketch in my mind for a new undo abstraction -- basically a generic undo stack and a 'log entry' base class that variuos subsystems can subclass for undoing/redoing specific things.
We could even use it for the next/prev zoom feature (i.e. use one of these generic undo stacks for document editing history, and another for zoom history).
It's very nice, but currently I'm concerned about this particular bug. I think it must be fixed before the release, because it's pretty annoying. Sometimes (I couldn't figure exactly when) editing text even breaks undo completely, i.e. I get "operation did not complete transaction" and cannot undo any more.
_________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2f...