To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=91504


User mst changed the following:

                What    |Old value                 |New value
================================================================================
                      CC|'kpalagin,pj'             |'kpalagin,majun51,pj'
--------------------------------------------------------------------------------




------- Additional comments from m...@openoffice.org Mon Sep 28 16:34:27 +0000 
2009 -------
hi majun51,

i have had a look at your patch, and tried it out.
sorry that it took so long, but i've had no time before, and the redlining code
is rather... complicated.

(aside: the patch is inverted, because you put the parameters to diff in the
wrong order; just a minor inconvenience)

Your patch unfortunately introduces a local variable nOffset; the class
SwUndoRedlineSort already has a member of the same name. This fails to build
with the Solaris compiler. Please rename your variable.

So, the problem is that the sort with redline on is implemented as a copy of the
selected nodes, followed by sorting of the original nodes, and marking the
inserted copy of the nodes (which are in original order) as a delete redline.
When the copied nodes contain frames, then these frames are also copied.
Because of the awful way frames are represented in the writer model, namely, a
section in a special area of the nodes array that precedes the body of the
document, this changes the offsets of the nodes in the sorted text.

It seems to me that the patch actually fixes the hang which is described in this
issue, by remembering the previous node (before the selection), and updating the
node indices stored in the undo object to account for the removed frames on UNDO
(and also, the inserted frames, on REDO).

Unfortunately, there is also another problem.
In order to reproduce this problem, you need to have the following:
- selection with paragraphs with a frame, as described above
- a DELETE redline in the selection
- the menu option Edit->Changes->Record must be ON
- the menu option Edit->Changes->Show must be OFF

Without the patch, on UNDO, the document content seems corrupted:
the delete redline with the copy of the nodes that was inserted by the sort is
not removed.
With the patch, on UNDO, it crashes when dereferencing pCNd->Len(),
because pCNd is 0.

The reason for this is the constructor of SwUndoRedline, and its Undo/Redo 
methods.
The code checks if there are hidden redlines in the selection, and calculates an
offset.
Apparently something is going wrong there and the offset is not correct.
(Also, i do not fully understand why there is a call to pRedlUndo->SetValues in
SwDoc::SortText)

Probably the easiest way to solve this problem would be to set the redline mode
to show all redlines in the SwDoc::SortText method (and reset it before
returning), as is done for other SwDoc methods already.

Alternatively, you could try to find out where the accounting of
SwUndoRedlineSort::nOffset goes wrong.

---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org
For additional commands, e-mail: issues-h...@sw.openoffice.org


---------------------------------------------------------------------
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org

Reply via email to