Home » Eclipse Projects » JFace » Re: CCombo updates in Eclipse 3.4.
| Re: CCombo updates in Eclipse 3.4. [message #4707] |
Wed, 13 May 2009 11:59  |
Eclipse User |
|
|
|
Hi,
ColumnViewerEditor is new since 3.3 and it is correct that CCombo since
3.4 provides us with new features like providing mouse-events.
I could swear since CCombo is giving us the events appropriately what
happens is that ColumnViewerEditor catches the second click and
interprets it as a Double-Click on the Table/Tree (this worked for all
other editors in all the time).
We could have introduced special code to not translate CCombo-Clicks but
decided against it because now all CellEditors show consitent behaviour
and because one can control this behaviour:
a) For all CellEditors through passing a constant when setting up the
ColumnViewerEditor. See
ColumnViewerEditor#KEEP_EDITOR_ON_DOUBLE_CLICK
b) On a CellEditor-base by returning 0 from the the
CellEditor#getDoubleClickTimeout()
For ComboCellEditors we also introduced some more nice features like
automatically poping up (see AbstractComboBoxCellEditor).
This looks like a JFace topic so I'd say you should follow up there if
you have other questions (I already set the newsheaders-appropriately
and CC'ed the JFace-group).
Tom
Irum Godil schrieb:
> Hi Grant,
>
> I am sorry i did not get a chance to follow up on this earlier. So, I
> did trace the notifyListeners, and there is a typedListener, which goes
> into "ColumnViewerEditor" class into the mouseDown event, and removes
> our original editor from the list of listeners. I cannot find the same
> "ColumnViewerEditor" class in 3.2, but even if it is there with same
> logic, since there was no MouseDown event, our code worked as expected.
> Is there a way I can disable the "MouseDown" event from the "CCombo" in
> our specific editor?
>
> Thanks.
> Irum.
>
> Grant Gayed wrote:
>
>> The only part of the commented-out MouseDown case that should make any
>> difference is the event.doit=... line. Is someone listening for
>> MouseDown
>> events on the CCombo (or adding a filter for them on the Display) and
>> setting the event's doit to false? The best way to determine this is
>> to put
>> a breakpoint at the notifyListeners(...) line and trace through to see
>> any
>> listeners that are being notified of the MouseDown.
>
>> Grant
>
>
>> "Irum Godil" <irum@ca.ibm.com> wrote in message
>> news:cfc88f8cb5af97f65e95cb4169ef1e3e$1@www.eclipse.org...
>>> Hi,
>>>
>>> We have a bug in our system, where we are using an editor based on
>>> CCombo.
>>> Previously, whenever the user would click on the drop down arrow of a
>>> CCombo, the contents of the drop down would appear right away. In
>>> 3.4, we
>>> have to keep clicking the combo numerous times before the drop down
>>> appears.
>>>
>>> The entire combo itself appears to be selected a lot of times, until we
>>> can get the drop down contents.
>>>
>>> I have found the problem is that in the "arrowDown" API, the following
>>> event handler has been added for MouseDown. If I comment it out, my code
>>> works fine, as there is no event in SWT.MouseDown and the code goes to
>>> SWT.Selection.
>>>
>>> How can I get the original behaviour, where we can by-pass this
>>> MouseDown
>>> event code from executing? Since so many of our classes use CCombo,
>>> overriding the class is not an option.
>>>
>>> I will really appreciate if someone can suggest how to solve this
>>> problem.
>>>
>>> Thanks.
>>>
>>> void arrowEvent (Event event) {
>>> switch (event.type) {
>>> case SWT.FocusIn: {
>>> handleFocus (SWT.FocusIn);
>>> break;
>>> }
>>> // case SWT.MouseDown: {
>>> // Event mouseEvent = new Event ();
>>> // mouseEvent.button = event.button;
>>> // mouseEvent.count = event.count;
>>> // mouseEvent.stateMask = event.stateMask;
>>> // mouseEvent.time = event.time;
>>> // mouseEvent.x = event.x; mouseEvent.y = event.y;
>>> // notifyListeners (SWT.MouseDown, mouseEvent);
>>> // event.doit = mouseEvent.doit;
>>> // break;
>>> // }
>>> case SWT.MouseUp: {
>>> Event mouseEvent = new Event ();
>>> mouseEvent.button = event.button;
>>> mouseEvent.count = event.count;
>>> mouseEvent.stateMask = event.stateMask;
>>> mouseEvent.time = event.time;
>>> mouseEvent.x = event.x; mouseEvent.y = event.y;
>>> notifyListeners (SWT.MouseUp, mouseEvent);
>>> event.doit = mouseEvent.doit;
>>> break;
>>> }
>>> case SWT.Selection: {
>>> text.setFocus();
>>> dropDown (!isDropped ());
>>> break;
>>> }
>>> }
>>> }
>>>
>
>
|
|
|
| Re: CCombo updates in Eclipse 3.4. [message #4776 is a reply to message #4707] |
Wed, 13 May 2009 12:03  |
| Eclipse User |
|
|
|
Hi Tom,
Thanks for forwarding it to the JFace Group, I will follow it up there.
Regards,
Irum.
Tom Schindl wrote:
> Hi,
> ColumnViewerEditor is new since 3.3 and it is correct that CCombo since
> 3.4 provides us with new features like providing mouse-events.
> I could swear since CCombo is giving us the events appropriately what
> happens is that ColumnViewerEditor catches the second click and
> interprets it as a Double-Click on the Table/Tree (this worked for all
> other editors in all the time).
> We could have introduced special code to not translate CCombo-Clicks but
> decided against it because now all CellEditors show consitent behaviour
> and because one can control this behaviour:
> a) For all CellEditors through passing a constant when setting up the
> ColumnViewerEditor. See
> ColumnViewerEditor#KEEP_EDITOR_ON_DOUBLE_CLICK
> b) On a CellEditor-base by returning 0 from the the
> CellEditor#getDoubleClickTimeout()
> For ComboCellEditors we also introduced some more nice features like
> automatically poping up (see AbstractComboBoxCellEditor).
> This looks like a JFace topic so I'd say you should follow up there if
> you have other questions (I already set the newsheaders-appropriately
> and CC'ed the JFace-group).
> Tom
> Irum Godil schrieb:
>> Hi Grant,
>>
>> I am sorry i did not get a chance to follow up on this earlier. So, I
>> did trace the notifyListeners, and there is a typedListener, which goes
>> into "ColumnViewerEditor" class into the mouseDown event, and removes
>> our original editor from the list of listeners. I cannot find the same
>> "ColumnViewerEditor" class in 3.2, but even if it is there with same
>> logic, since there was no MouseDown event, our code worked as expected.
>> Is there a way I can disable the "MouseDown" event from the "CCombo" in
>> our specific editor?
>>
>> Thanks.
>> Irum.
>>
>> Grant Gayed wrote:
>>
>>> The only part of the commented-out MouseDown case that should make any
>>> difference is the event.doit=... line. Is someone listening for
>>> MouseDown
>>> events on the CCombo (or adding a filter for them on the Display) and
>>> setting the event's doit to false? The best way to determine this is
>>> to put
>>> a breakpoint at the notifyListeners(...) line and trace through to see
>>> any
>>> listeners that are being notified of the MouseDown.
>>
>>> Grant
>>
>>
>>> "Irum Godil" <irum@ca.ibm.com> wrote in message
>>> news:cfc88f8cb5af97f65e95cb4169ef1e3e$1@www.eclipse.org...
>>>> Hi,
>>>>
>>>> We have a bug in our system, where we are using an editor based on
>>>> CCombo.
>>>> Previously, whenever the user would click on the drop down arrow of a
>>>> CCombo, the contents of the drop down would appear right away. In
>>>> 3.4, we
>>>> have to keep clicking the combo numerous times before the drop down
>>>> appears.
>>>>
>>>> The entire combo itself appears to be selected a lot of times, until we
>>>> can get the drop down contents.
>>>>
>>>> I have found the problem is that in the "arrowDown" API, the following
>>>> event handler has been added for MouseDown. If I comment it out, my code
>>>> works fine, as there is no event in SWT.MouseDown and the code goes to
>>>> SWT.Selection.
>>>>
>>>> How can I get the original behaviour, where we can by-pass this
>>>> MouseDown
>>>> event code from executing? Since so many of our classes use CCombo,
>>>> overriding the class is not an option.
>>>>
>>>> I will really appreciate if someone can suggest how to solve this
>>>> problem.
>>>>
>>>> Thanks.
>>>>
>>>> void arrowEvent (Event event) {
>>>> switch (event.type) {
>>>> case SWT.FocusIn: {
>>>> handleFocus (SWT.FocusIn);
>>>> break;
>>>> }
>>>> // case SWT.MouseDown: {
>>>> // Event mouseEvent = new Event ();
>>>> // mouseEvent.button = event.button;
>>>> // mouseEvent.count = event.count;
>>>> // mouseEvent.stateMask = event.stateMask;
>>>> // mouseEvent.time = event.time;
>>>> // mouseEvent.x = event.x; mouseEvent.y = event.y;
>>>> // notifyListeners (SWT.MouseDown, mouseEvent);
>>>> // event.doit = mouseEvent.doit;
>>>> // break;
>>>> // }
>>>> case SWT.MouseUp: {
>>>> Event mouseEvent = new Event ();
>>>> mouseEvent.button = event.button;
>>>> mouseEvent.count = event.count;
>>>> mouseEvent.stateMask = event.stateMask;
>>>> mouseEvent.time = event.time;
>>>> mouseEvent.x = event.x; mouseEvent.y = event.y;
>>>> notifyListeners (SWT.MouseUp, mouseEvent);
>>>> event.doit = mouseEvent.doit;
>>>> break;
>>>> }
>>>> case SWT.Selection: {
>>>> text.setFocus();
>>>> dropDown (!isDropped ());
>>>> break;
>>>> }
>>>> }
>>>> }
>>>>
>>
>>
|
|
|
Goto Forum:
Current Time: Sat May 10 15:43:01 EDT 2025
Powered by FUDForum. Page generated in 0.04051 seconds |
Home