I've
seen a problem in areas of our text widget listeners which are handling
some important events, and I've tracked the problem down to a difference
in the ordering of the events from Eclipse 2.1.x to Eclipse 3.0 which is
caused by a difference in implementation from Control.sendKeyEvent(int,
int, int, int, Event). I am requesting information about why the following
change was made and how we should react to it.
In Eclipse 2.1.x we have:
boolean sendKeyEvent (int type, int
msg, int wParam, int lParam, Event event) {
postEvent
(type, event);
return
true;
}
But in Eclipse 3.0 we have:
boolean sendKeyEvent (int type, int
msg, int wParam, int lParam, Event event) {
sendEvent
(type, event);
//
widget could be disposed at this point
/*
*
It is possible (but unlikely), that application
*
code could have disposed the widget in the key
*
events. If this happens, end the processing of
*
the key by returning false.
*/
if
(isDisposed ()) return false;
return
event.doit;
}
postEvent() and sendEvent() both call
out to Widget.sendKeyEvent(int, Event, boolean) [below] but vary the value
of the boolean at the end of the method.
The lines in this method were put in
the CVS repo by Steve Northover (steve_northover@xxxxxxxxxx) in early June
2003 in org.eclipse.swt.widgets/Eclipse SWT/win32/org/eclipse/swt/widgets/Control.java
versions 1.134 and 1.137 on 06/05/2003 and 06/13/2003 respectively. They
list defects 25257 and 38841 in their comments.
These were:
Bug 25257 [Key Bindings] Cannot associate
a key binding with a dialog --> associated with the first line of the
method
Bug 38841 NPE in Widget.filters --->
this is associated with the remaining lines
Bug 25257 seems to be where the semantic
change occurred. I have copied the text of the defect comments below. Nothing
seems obvious why they would have made this change. My first run through
the method I thought it was doing the same thing as well (it was only a
"little" boolean on the end that was different ...). I'm curious
if the change was made originally trying to clean up the call, since postEvent()
did and still does delegate the method through to sendEvent() --> "
void postEvent (int eventType, Event event) { sendEvent (eventType, event,
false); } "
20021022
I would like to have the copy functionality on the MultiErrorDialog but
I need
API to register the widget (a list) with the copy action.
------- Additional Comment #1
From Chris
McLaren 2002-12-02 14:08 ------- You should not need special API outside the key binding
service.
SWT's accelerator implementation doesn't allow the key binding service
to
define accelerators on dialogs.
Moving to SWT and upgrading to critical.
------- Additional Comment #2
From Christophe
Cornu 2002-12-03 09:23 ------- SN to investigate and advise
------- Additional Comment #3
From Veronika
Irvine 2003-01-24 10:08 ------- Steve, This is marked critical. Please
investigate and adjust
severity/prioerity accordingly.
------- Additional Comment #4
From Tod
Creasey 2003-01-24 11:13 ------- FYI we have a workaround for this case currently in
place for 2.1
------- Additional Comment #5
From Steve
Northover 2003-10-01 10:05 ------- There is not plan to implement an accelerator service
that is independent of
the menu bar. With the advent of Display.addFilter() and recent changes
to
SWT.KeyDown, programmers who insist on defining an accelerator mechanism
that
is non-standard can do so.
Can anyone offer any information about
this change and more importantly how we should react to it? The listener
we have attached to the widgets should not be notified until *after* the
change hits the widget. Right now, we are notified about the widget *before*
the value of the widget changes.