Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Changing the String property of a text range also changes the neighboring range | ||||||
---|---|---|---|---|---|---|---|
Product: | Writer | Reporter: | akrioukov <basileia> | ||||
Component: | code | Assignee: | stephan.wunderlich | ||||
Status: | CLOSED FIXED | QA Contact: | issues@sw <issues> | ||||
Severity: | Trivial | ||||||
Priority: | P3 | CC: | issues | ||||
Version: | OOo 1.1 RC5 | ||||||
Target Milestone: | --- | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
Developer Difficulty: | --- | ||||||
Attachments: |
|
Description
akrioukov
2004-06-07 16:38:10 UTC
Created attachment 15718 [details]
Text document with a macro allowing to reproduce the problem.
MRU->SW: looks like API stuff. SW->TL: the macro searches for 'z' and wants to replace it by 's' .... findAll() returns as expected {z,z,z,z} for thizzzz, but when the first z is replaced with an 's' the content of the container changes to {z, sz, z , z} ... this way 'thizzz' is transformed to 'this' by simply replacing 'z' with 's' instead of the expected 'thissss'. I could reproduce this behaviour in OOo1.0.1, OOo1.1.0 and OOo1.1.1, so it seems to be not as new as mentioned in the description. Anyway this behaviour differs from the expectation and the behaviour in the UI so it should be taken into account to get it solved in OOo2.0. . The problem is that bookmarks which are used to specify the text range grow when text is inserted directly before them. Since searching for "z" in a text like "zzzzz" results in 5 bookmarks (XTextRanges) following directly each other, replacing the first results indirectly in having the second extended by the new inserted text and so on. Unfortunately it is not as simple as using an uno cursor for the implementation since those grow by text inserted directly after it. Need to check with OS and AMA what to do. Code references: - SwXTextRange::DeleteAndInsert - SwTxtNode::Update - SwIndexReg::Update A workaround for the current implementation would be to replace the strings in reverse order i.e. starting with the one last found. Fixed in CWS tl03. Files changed: - ndtxt.cxx new revision: 1.36.38.1 . . . OK in CWS tl03. looks good in cws_tl03 => verified ok in src680_m66 => closed |