Well, as a matter of principle SPXMLViewContent shouldn't have to know anything about desktops -- the calls to sp_desktop_done() should be happening in src/dialogs/xml-tree.cpp.
Not desktop, but document! Surely it must know its document - if it's editing this document. So what's the best way to figure out the document? Can we -> our way from a repr to its document? Or can we pass the SPDocument pointer in a data attached to the dialog or widget?
- Now that the text node changes are undoable, undoing editing a text
object in XML editor has the same problem as in this bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=861462&grou...
That is, if you create a text node, switch to any other tool, and then reproduce this bug's sequence but using XML editor instead of F8, the
result
is the same. Which proves that the source of the problem is not text
tool,
but the wrong way text node changes are logged and undone by the repr logger. It was only obvious in text tool because no other tools
create/edit
text nodes. Can you please have a look into it?
Sourceforge is down again, so I can't get to the bug tracker. Could you please summarize the bug for me in more detail?
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).
-mental << signature.asc >>
_________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2f...