Apache OpenOffice (AOO) Bugzilla – Issue 3117
Cursor placement too limited when using the thesarus
Last modified: 2013-08-07 14:41:36 UTC
When the cursor is at the end of a word and the user brings up the thesarus, either by pressing ctrl-F7 or going to the tools menu, a word is not automatically selected in the thesarus. Instead, a user must highlight the word for it to be selected. I think the OpenOffice thesarus should be set to select a word for the thesarus when the cursor is in 1. at the beginning of the word, 2. at the end of the word, or 3. in between any of the letters of the word the user wishes to look up in the thesarus. It would make things much, much easier for people who frequently use the thesarus. Thank you, RA
TL: It should work the same way in OpenOffice as in StarOffice. For example if you have the word "General" you may place the cursor from right before the 'G' to right before the 'l' (not right after(!) though) to start the thesaurus with the word the cursor is in. TL->SBA: Is the behavior in OpenOffice different from the one in StarOffice?
Reassigned to Michael.
The behaviour in StarOffice/OpenOffice is the same. But in comparision to SO 5.2, it got a little bit worse. I StarOffice 5.2 it was also possible to place the cursor right after the word and then call the Thesaurus. This little Feature we lost. Also when a word is followed be a comma and the cursor is placed between the comma and the word, the Thesaurus dialog shows the comma as expression. Here SO 5.2 worked also much better.
(empty comment)
*** Issue 10778 has been marked as a duplicate of this issue. ***
lowered priority to 3. Issue is not essential.
Changed type back to defect since it was OK in SO 5.0.
It looks like internal bug #106385# should be integrated before this is getting fixed. Will ask Karl which version that will be. The place where this is to be fixed then is sw/*/txtedt.cxx: XubString SwTxtNode::GetCurWord( xub_StrLen nPos )
Need to wait for CWS i18n03 (i.e. internal bug #106385#) to be integrated before proceeding with this one.
CWS i18n03 is integrated in SRX644 m4s3. That is this one can be fixed in a CWS based upon m5.
Files changed: sw: txtedt.cxx 1.37.2.2.32.1 See also #i11993#, when that issue is fixed the fix to this one should be functional without further code modifications.
The fix itself should be in CWS sw008.
TL: reopened. Fix will remain in CWS sw008 and be integrated with that CWS. Since it can be verified only when #i11993# got fixed I reopen it for now.
TL->Karl: For the time being I reassign this one to you since I may not notice when #i11993# gets fixed. If that one is fixed please hand this one over back to me and state the version where #i11993# will be integrated in order for me to check this bug again.
Karl->TL: i11993 is fixed in CWS apps61beta2. Please check it.
With my part being done already in sw008 there should ne nothing left than to test that everything is working in CWS apps61beta2.
.
OD->MRU (22.04.2003): Checked in internal installation set of CWS apps61beta2. Please verify.
Checked fix with CWS apps61beta2
Verified. Fix will be included in OO 1.1 Beta.
due to problems while fixing #11993 this fix will happen earliest in OO 1.1 final. Sorry!
Changed target to 1.1 final.
TL: As dicussed with MI I will change the target to OO 2.0 in order to have time to discuss this and it' impact in more detail.
reassign.
tested on src680_m33, bug is fixed.
bug closed.