Community
Participate
Working Groups
The keyboard user pressed ALT+DOWN to drop down the list of recent target platforms, then presses DOWN_ARROW several times to select the desired target platform from the MRU list. But the UI receives selection change and agressively rescans the target platform on *every* DOWN_ARROW key. This is very annoying when you are trying to navigate 2 or more entries.
This seems like an SWT combo issue. We reload the target platform plug-ins upon selection change in the combo box. Perhaps, gratuitous events are being fired when using the DOWN_ARROW key.
Combo does fire Selection on each down-arrow in this scenario, but this is the correct behaviour since arrowing selects the item that is traversed to (ie.- arrow down a couple of times, then press escape to cancel the dropdown, and note that the last selected item is the final selection). This can be seen in other native windows contexts such as setting the date/time.
Internet Explorer's address bar does not browse to the selected location until you press ALT+UP or ENTER. So it depends on the context and what actually occurs when the new selection is "processed".
Grant, I see your point, but this is clearly the wrong behavior in this context. Loading the target platform can take a while for products like WSADIE (~2000 plugins), so doing it on every DOWN ARROW is clearly not desired. Is there anything that I can do at my end to distinguish or be able to tell what causes the selection to change?
There is a difference in that Traverse events with detail SWT.TRAVERSE_ARROW_NEXT or SWT.TRAVERSE_ARROW_PREVIOUS are fired in the keyboard case. However there's no way to differentiate between arrowing in the combo's text field (which should select each traversed item) and arrowing in the combo's list (which in this context should not select each traversed item). I tried to make a snippet that would make the combo behave like the one in IE, but could not make it work for this reason. An easy way to see the events fired by Combos is through the swt Control Example contained in the eclipse example plugins. The alternatives this leaves are to either change the UI (eg.- a separate button beside the combo that says "go parse 2000 plugins" [sic], use a list instead of the combo, etc.), or fake the combo look with a NO_TRIM shell that pops up. The first option would be much easier, if an appopriate ui change can be determined.
bug 54989 is related and talks about a request for an SWT event when the drop- down is "rolled up".
>The alternatives this leaves are to either change the UI (eg.- a separate >button beside the combo that says "go parse 2000 plugins" [sic], use a list >instead of the combo, etc.), If we were to do it this way, we don't even need to change the UI. We can keep the combo box, as there is already a 'Reload' button. So people can change the selection in the combo box without PDE doing anything upon selection change. When they explicitly hit Reload, then we would parse the plug-ins. This is how we did it in the past and got many requests to automatically load the plug-ins upon the selection of a new target location. People were tired of pressing the 'Reload' button ;-) So that is why we're in this situation right now.
You could always use a timed delay :-P! fun! Preference dialog does this.
I just opened another form of this bug: bug 110995 slightly different because the annoyance is not time to respond, but throwing focus to another widget.
sorry, I meant bug 111364.
We have to close on this issue as this is annoying more and more people and target platforms are getting larger and larger. see also bug 175321 for a related issue but on Linux only. When the text is modified manually by the user, he will have to press 'Reload' to, well, reload. If he forgets to press 'Reload' and tries to exit the preference dialog, PDE will pop up a reminder and ask to reload for him or cancel. When the user chooses a new location via the Browse... button, we will auto-reload as usual.
