Community
Participate
Working Groups
Build ID: I20070621-1340 Steps To Reproduce: I've got an org.eclipse.jface.fieldassist.AutoCompleteField installed on an org.eclipse.swt.widgets.Combo. Some strings in the combo are prefixes of others. I want autocompletion to be activated when I type in the combo, but not when I select something from its drop-down component, because when I do that I have finished making my choice. But it also activates when I select an item that's a prefix of another one. It seems that the listener in the ContentProposalAdapter is being triggered by an SWT.Modify event from the combo. The platform is Linux/GTK. More information: Code to reproduce: Composite composite; // Get a composite somehow String[] items = new String[] {"One", "Two", "Two hundred"}; Combo combo = new Combo(composite, SWT.DROP_DOWN); combo.setItems(items); new AutoCompleteField(combo, new ComboContentAdapter(), items); Run this. Select "Two" in the combo (assuming it's not selected already). An auto-complete popup appears, containing "Two hundred".
Seems like an AutoCompleteField issue, moving to UI.
I'll investigate during M3 along with other multi-platform field assist issues
This bug is platform independent. Oh, what a tangled web we weave. I added the hook to SWT.Modify while fixing bug #147377. From that bug... >This does bring up an issue in the auto-complete case. If the keystroke and >autoactivate characters are null, which is typically true for autocomplete, >then how do we decide to reopen the popup? The spec says that the >popup should be autoactivated for alphanumeric keys, but the reality is that >the popup should be reopened if any content change occurs, caused by BS, DEL, >or some other manipulation. When the popup never auto-closed, this was not >an issue. Now that it closes on empty proposal lists, we need to reopen it >on any content change in the control. This required hooking an additional >listener on SWT.Modify rather than simply watching the keystrokes for >alphanumeric keys. While not strictly to spec (not all content changes are >caused by alphanumeric keys), I think this is the intention for autocomplete. need to investigate only honoring an SWT.Modify when we auto-closed the popup. Yuck.
Fixed in HEAD >20070927. I had to rethink the solutions to bug #147377 and bug #183650. Rather than always watch the Modify event and decide when to ignore it, I reversed the logic to decide explicitly the cases where the Modify should be watched. The risk is that we miss opening the popup in some cases (don't know of any but let's assume I've missed a subtle case). This is better than bogusly opening the popup when I've missed a case to ignore it.
verified on WinXP, I20071029-0800, using latest field assist example (bug was platform independent)
