Issue 106158 - Generating new AutoCorrect entry removes all entries
Summary: Generating new AutoCorrect entry removes all entries
Status: CLOSED DUPLICATE of issue 105760
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: DEV300m60
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: mikhail.voytenko
QA Contact: issues@framework
Depends on:
Blocks: 99999
  Show dependency tree
Reported: 2009-10-21 17:21 UTC by stefan.baltzer
Modified: 2009-10-26 07:31 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

scenario (105.11 KB, image/jpeg)
2009-10-22 12:14 UTC, majukr05
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description stefan.baltzer 2009-10-21 17:21:29 UTC
New Writer doc
 - Tools - AutoCorrect Options, Tab "Replace"
 - In listbox on top, choose a laguage that has entries, i.e. English (US)
 - Enter a new AutoText (i.e. replace "aa" with "aaa")
 - Click "New" so that a new entry in the list is created.
 - Click OK to close dialog
 - Reopen dialog (tools - AutoCorrect Options)
-> The AutoCorrect list for this language is empty.

This worked well in DEV300_m60, broken since m61.

Note: By default, the AutoCorr files are in the shared tree. As soon as the user
alters it (add or remove entries), the respective modified autocorrection file
is copied to the user tree and thereafter this one is used. After the above
scenario, the file in the user tree has a size of 0 kB.
Comment 1 stefan.baltzer 2009-10-21 17:40:46 UTC
Correction: Worked well in DEV300_m59, broken since DEV300_m60
Comment 2 majukr05 2009-10-21 18:17:41 UTC
There's also the similar Issue 105640 - Autocorrect list erased when accessed
trying to add entry (Status: unconfirmed) ...
Comment 3 Oliver Specht 2009-10-22 07:08:34 UTC
->mav: Could this be a problem in some storage/package code?
Comment 4 tommy27 2009-10-22 08:18:56 UTC
has this issue anything to do with issue
show_bug.cgi?id=87672 "autocorrect limit. acor.dat with entry 65535: Loop and/
or loss of acor data" ?
Comment 5 mikhail.voytenko 2009-10-22 08:51:35 UTC
That might be a duplicate to issue 105082, that is fixed in DEV300_m61 and
OOO320_m1. The problem there was that the truncation of the file stream did not
always work as expected.

Please try OOO320_m1 or later with the scenario.
Comment 6 majukr05 2009-10-22 12:10:47 UTC
Scenario tested with
- OOo-dev 3.2.0 OOO320_m2 (Build 9432)
- OOo-dev 3.2.0 DEV300_m62 (Build 9433)
Result: broken in both 
Comment 7 majukr05 2009-10-22 12:14:38 UTC
Created attachment 65534 [details]
Comment 8 Oliver Specht 2009-10-23 14:51:00 UTC
reassigned to mav
Comment 9 mikhail.voytenko 2009-10-23 15:08:06 UTC
This is a duplicate to issue 105760.

*** This issue has been marked as a duplicate of 105760 ***
Comment 10 mikhail.voytenko 2009-10-23 15:08:41 UTC
Comment 11 tommy27 2009-10-24 10:03:39 UTC
are you really sure that this issue is really a duplicate of Issue 105760 
"Extensible Help: Content not displayed"...

they seems 2 different things to me... but maybe I'm wrong...
Comment 12 mikhail.voytenko 2009-10-24 13:45:15 UTC
mav->tommy27: You are right, these are completely different things. But the
implementations use the same API to generate the archive, this API is now fixed
in cws fwk125 for issue 105760.
Comment 13 tommy27 2009-10-24 20:08:44 UTC
let me see if i get it...
did you say that fixing the API for issue 105760, fixed issue 106158 as well 
despite being two different things?
Comment 14 mikhail.voytenko 2009-10-26 07:31:49 UTC
mav->tommy27: It is probably better if I describe it with more details. The
AutoCorrection implementation uses Package UCP API to generate the new archive
in the mentioned here scenario.  

The scenario from issue 105760 also uses Package UCP API to generate the new
archive containing entries related to the extension mentioned there.

There was a problem in the Package UCP implementation that has affected both
scenario, although they are completely different implementations. After the
problem was fixed in the cws fwk125 both scenarios work well there.