Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Writer loops after deleting invisible recorded changes and Undo | ||||||
---|---|---|---|---|---|---|---|
Product: | Writer | Reporter: | amy2008 <amy2008> | ||||
Component: | code | Assignee: | michael.ruess | ||||
Status: | CLOSED FIXED | QA Contact: | issues@sw <issues> | ||||
Severity: | Trivial | ||||||
Priority: | P2 | CC: | issues, jun.ma, mst.ooo, ooo.redflag | ||||
Version: | DEV300m37 | ||||||
Target Milestone: | --- | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
Developer Difficulty: | --- | ||||||
Issue Depends on: | |||||||
Issue Blocks: | 84292 | ||||||
Attachments: |
|
Description
amy2008
2008-12-19 08:35:40 UTC
MRU->AMA: follow the described steps and Writer will be caught in a loop after using Undo in the end. Issue 97420 and Issue 97421, they are related to 'UNDO' which contains empty entries in the listitem. ama_>mba: Not sure, who could take care of this.. Created attachment 64332 [details]
patch file
Please have a check,thanks in advance. hi mba, Could you please check this patch and point out if anything wrong or missed? Thanks very much.(It seems solve Issue 97420 too ) In this patch: - changed a critical case in ComparePosition() - saved nodes for the hidden redlines Thanks for the patch, I will have a look at it soon. hi mba, I tested a some bigger document which contains some redlines in and found it spend too much time on openning file... it's because my change in ComparePosition() in the patch. So please give it up. i just changed "if( rStt1 < rStt2 )" to "if( rStt1 <= rStt2 )". The ComparePosition() is called in AppendRedline() and according result returned from ComparePosition(), many redlines will be inserted into pRedlineTbl. Could you please give me some suggestions about the logic to handle redlines here? I will continue working on this issue. hi majun51, i'm sorry, but your proposed change to ComparePosition is wrong: try e.g. 2 positions with same start and end, which should return EQUAL, but returns OUTSIDE. It seems the return value of ComparePosition is not very well defined if start and end of one range are equal; but i would recommend not changing ComparePosition, because nobody knows what that may break. While debugging i could see that there is a loop in SwDoc::AppendRedline for such redlines with no extent. It loops because the statement on line 923 "pRedl->SetStart" does not change the redline. Probably it would be better to just change the specific case in SwDoc::AppendRedline that loops, by checking in the POS_INSIDE case if one of the ranges is a point. This has the advantage that it is unlikely to break any unrelated functionality. Of course this has the disadvantage that it makes AppendRedline even more complicated, but i cannot think of a better approach. please take over @majun51: after not hearing from you for some time, i've tried to fix the issue myself now. you were right about the second part of your patch. because on Undo, the RestoreSection method clears the section pointer (pMvStt), the Redo implementation must re-create the redline data. this was not clear to me initially, because this problem only occurs on Redo. the other half of the fix is a change in AppendRedline, as described in my previous comment. thanks for your patch! fixed in cws sw33bf04 http://hg.services.openoffice.org/hg/cws/sw33bf04/rev/f78229069e7b please verify Verified in CWS sw33bf04. Checked in DEV300m83. |