Home » Eclipse Projects » Standard Widget Toolkit (SWT) » Selection event for CCombo should not fire when arrow-navigating in the dropDown
| Selection event for CCombo should not fire when arrow-navigating in the dropDown [message #496456] |
Tue, 10 November 2009 07:52  |
 Viliam Durina
Messages: 13
Registered: July 2009 |
Junior Member |
|
|
This is a multi-part message in MIME format.
--------------040307040702070601020302
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit
In current implementation (SWT 3.5.1), CCombo fires Selection event, if the user navigates in the drop-down box using arrows. I think this is not necessary, especially in case of READ_ONLY combo-boxes. I have processing attached to Selection event and it fires to often from the user point of view. The standard Combo (at least under Windows) does not behave like this.
What others think about this? I made a patch for me that I'd like to be included in the next release.
Viliam
--------------040307040702070601020302
Content-Type: text/plain;
name="CCombo.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="CCombo.diff"
59a60
> String preDropDownValue;
520a522,524
> // send Selection event, if the value was changed since dropDown(true)
> if ( ! preDropDownValue.equals(text.getText()))
> notifyListeners(SWT.Selection, null);
521a526,528
> } else {
> // keep original value before showing dropDown for comparison
> preDropDownValue = text.getText();
1032a1040,1046
> // post the value from list to text for selection event fired in dropDown(false)
> int index = list.getSelectionIndex ();
> if (index == -1) return;
> text.setText (list.getItem (index));
> text.selectAll ();
> list.setSelection (index);
>
1042c1056,1057
< Event e = new Event ();
---
> // Don't post the event here - will be posted in dropDown(false)
> /*Event e = new Event ();
1047c1062
< event.doit = e.doit;
---
> event.doit = e.doit;*/
--------------040307040702070601020302--
|
|
|
| Re: Selection event for CCombo should not fire when arrow-navigating in the dropDown [message #496885 is a reply to message #496456] |
Wed, 11 November 2009 15:53  |
Grant Gayed
Messages: 2150
Registered: July 2009 |
Senior Member |
|
|
Hi Viliam,
When you say "arrows" you mean the arrow keys, right? Assuming so, this
behaviour does match what I see in Combos on win32. This is needed because
arrowing through the items does select them (ie.- pressing Esc
dismisses/cancels the list but does not revert the selection to its previous
value). The previously-logged bug for Combo selection on win32 is
https://bugs.eclipse.org/bugs/show_bug.cgi?id=95479 .
There's no requirement for CCombo's behaviour to match Combo, but doing so
where possible is desirable since these behaviours are generally well
thought-out and expected by users. The behaviour that you want matches gtk
but not win32, so there's no obvious "correct" behaviour here. I would
suggest logging a Feature Request with SWT (
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Platform &component=SWT&bug_severity=enhancement )
and provide a patch with the proposed change. I don't know if it will be
taken or not, it depends on whether others agree with the change (mention
that GTK's Combo behaves like this). Also, your patch format doesn't look
like one that is easily applied here, the best steps for creating a patch
are:
- retrieve swt from cvs: http://www.eclipse.org/swt/cvs.php
- make your changes to the org.eclipse.swt project in your workspace
- select the org.eclipse.swt project, right-click, invoke Team > Create
Patch...
Grant
"Viliam Durina" <viliam.durina@gmail.com> wrote in message
news:hdb63l$rbm$1@build.eclipse.org...
> In current implementation (SWT 3.5.1), CCombo fires Selection event, if
the user navigates in the drop-down box using arrows. I think this is not
necessary, especially in case of READ_ONLY combo-boxes. I have processing
attached to Selection event and it fires to often from the user point of
view. The standard Combo (at least under Windows) does not behave like this.
>
> What others think about this? I made a patch for me that I'd like to be
included in the next release.
>
> Viliam
>
------------------------------------------------------------ ----------------
----
> 59a60
> > String preDropDownValue;
> 520a522,524
> > // send Selection event, if the value was changed since dropDown(true)
> > if ( ! preDropDownValue.equals(text.getText()))
> > notifyListeners(SWT.Selection, null);
> 521a526,528
> > } else {
> > // keep original value before showing dropDown for comparison
> > preDropDownValue = text.getText();
> 1032a1040,1046
> > // post the value from list to text for selection event fired in
dropDown(false)
> > int index = list.getSelectionIndex ();
> > if (index == -1) return;
> > text.setText (list.getItem (index));
> > text.selectAll ();
> > list.setSelection (index);
> >
> 1042c1056,1057
> < Event e = new Event ();
> ---
> > // Don't post the event here - will be posted in dropDown(false)
> > /*Event e = new Event ();
> 1047c1062
> < event.doit = e.doit;
> ---
> > event.doit = e.doit;*/
>
|
|
|
| Re: Selection event for CCombo should not fire when arrow-navigating in the dropDown [message #497070 is a reply to message #496885] |
Thu, 12 November 2009 12:43 |
Viliam Durina
Messages: 13
Registered: July 2009 |
Junior Member |
|
|
Hi Grant,
In Slovak we press "arrow", not "arrow key" :)
I think that the order and count of delivered events should not be something considered native to platform, as most user don't see it. Event handling is one of the most challenging issue in SWT applications portability, which is another goal of SWT.
Navigating with arrow keys should be considered "browsing the items" not "selecting item by item". When I listen to SelectionEvent, I expect it to be delivered after the user browsed the items up and down and chose the one he wants, no matter whether by the keyboard or mouse. Do you think user will consider accepting the selection after pressing the enter key a non-windows behaviour? I think not.
Another example is that scroll event is delivered to a focused widget instead of to the one the mouse is over. This is much more annoying than the case with combobox. No modern Windows application except Eclipse scrolls in this stupid way, even though it is native to Windows. And programmers have to work it around and pay attention to break it not on GTK, where it works out of the box.
I'm not going to fill enhancement request as I have no hope (and it was already refused in bug you mentioned).
Viliam
Grant Gayed wrote / napísal(a):
> Hi Viliam,
>
> When you say "arrows" you mean the arrow keys, right? Assuming so, this
> behaviour does match what I see in Combos on win32. This is needed because
> arrowing through the items does select them (ie.- pressing Esc
> dismisses/cancels the list but does not revert the selection to its previous
> value). The previously-logged bug for Combo selection on win32 is
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=95479 .
>
> There's no requirement for CCombo's behaviour to match Combo, but doing so
> where possible is desirable since these behaviours are generally well
> thought-out and expected by users. The behaviour that you want matches gtk
> but not win32, so there's no obvious "correct" behaviour here. I would
> suggest logging a Feature Request with SWT (
> https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Platform &component=SWT&bug_severity=enhancement )
> and provide a patch with the proposed change. I don't know if it will be
> taken or not, it depends on whether others agree with the change (mention
> that GTK's Combo behaves like this). Also, your patch format doesn't look
> like one that is easily applied here, the best steps for creating a patch
> are:
>
> - retrieve swt from cvs: http://www.eclipse.org/swt/cvs.php
> - make your changes to the org.eclipse.swt project in your workspace
> - select the org.eclipse.swt project, right-click, invoke Team > Create
> Patch...
>
> Grant
>
>
> "Viliam Durina" <viliam.durina@gmail.com> wrote in message
> news:hdb63l$rbm$1@build.eclipse.org...
>> In current implementation (SWT 3.5.1), CCombo fires Selection event, if
> the user navigates in the drop-down box using arrows. I think this is not
> necessary, especially in case of READ_ONLY combo-boxes. I have processing
> attached to Selection event and it fires to often from the user point of
> view. The standard Combo (at least under Windows) does not behave like this.
>> What others think about this? I made a patch for me that I'd like to be
> included in the next release.
>> Viliam
>>
>
>
> ------------------------------------------------------------ ----------------
> ----
>
>
>> 59a60
>>> String preDropDownValue;
>> 520a522,524
>>> // send Selection event, if the value was changed since dropDown(true)
>>> if ( ! preDropDownValue.equals(text.getText()))
>>> notifyListeners(SWT.Selection, null);
>> 521a526,528
>>> } else {
>>> // keep original value before showing dropDown for comparison
>>> preDropDownValue = text.getText();
>> 1032a1040,1046
>>> // post the value from list to text for selection event fired in
> dropDown(false)
>>> int index = list.getSelectionIndex ();
>>> if (index == -1) return;
>>> text.setText (list.getItem (index));
>>> text.selectAll ();
>>> list.setSelection (index);
>>>
>> 1042c1056,1057
>> < Event e = new Event ();
>> ---
>>> // Don't post the event here - will be posted in dropDown(false)
>>> /*Event e = new Event ();
>> 1047c1062
>> < event.doit = e.doit;
>> ---
>>> event.doit = e.doit;*/
>
>
|
|
|
Goto Forum:
Current Time: Tue Apr 23 17:10:50 GMT 2024
Powered by FUDForum. Page generated in 0.02881 seconds |
] 
Search
Help
Register
Login
Home
