Community
Participate
Working Groups
I20100914-0100 Steps - Open a text editor - Ctrl+F - Type something in the 'Find' field - Press 'Enter' => Cursor moves to the beginning of the 'Find' field - not good. Seen this bug on GTK and Win XP Note: it is not reproducible always, but is easy enough to reproduce.
Rajesh, we should fix this for M2.
Created attachment 178901 [details] Fix Issue: Type/Paste a string in the Findfield that is not in its History list. Then press enter - the cursor will move to the beginning of the field. Cause: The History for the combo field (findfield) was being updated by clearing both the existing history + the string in the field and then setting both. This causes the cursor location in the field to be lost/reset. Solution: The history is now being updated without clearing/setting the contents of the field.
(In reply to comment #2) > Created an attachment (id=178901) [details] > Fix > > Issue: Type/Paste a string in the Findfield that is not in its History list. > Then press enter - the cursor will move to the beginning of the field. Also, if the string is in the history list but not the most recent(top) entry, pressing enter will move the cursor to the beginning.
The fix is not good. Steps: - type 111, Enter - clear field, type 222, Enter - open Find combo and select 111 - click Find => Find field is empty
Created attachment 178954 [details] Fix The Combo history code calls methods in org.eclipse.swt.widgets.Combo such as remove, setItem, etc which make the following OS call to delete items in the Combo list. - int result = (int)/*64*/OS.SendMessage (handle, OS.CB_DELETESTRING, start, 0); This call causes the Findfield to be cleared if the string in the field matches the string being deleted by the above call.
Comment on attachment 178954 [details] Fix Patch is too complicated (at least definitely for M2).
Created attachment 178965 [details] Fix
Rajesh, please test my fix and review it.
(In reply to comment #8) > Rajesh, please test my fix and review it. Good simplification :) Tested, works fine.
Dani has released his fix. Only minor problem is that the caret always ends up at the end of the selection even if it was at the beginning before. But there's no API in SWT to set the selection from right to left (SWT should already have a bug for that). Rajesh, please post the # of the SWT bug for the unexpected behavior from comment 5 here and make this bug depend on the SWT bug. We should remove the hacks in FindReplaceDialog#updateHistory(Combo, List) once that bug is fixed.
>But there's no API in SWT to set the >selection from right to left (SWT should already have a bug for that). Filed bug 325405.
Verified in I20100915-2024.
