Re: [platform-ui-dev] Change in the ordering of key events from Eclipse

[Mike Wilson <Mike_Wilson@xxxxxxxxxx>]

The change from postEvent to sendEvent was made to support global keyboard 
accelerators in eclipse.  The event must be sent so that the application 
can choose to use the key event as a global accelerator and therefore 
consume the event before the OS processes it (posted events are processed 
by the OS first).

If you require the text widget to already contain the character typed by 
the user, you should listen for a verify event rather than a key event.

Veronika Irvine




Michael Elder <mdelder@xxxxxxxxxx> 
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
23/06/04 10:11
Please respond to
platform-ui-dev


To
platform-ui-dev@xxxxxxxxxxx
cc

Subject
[platform-ui-dev] Change in the ordering of key events from Eclipse 2.1.x 
to Eclipse 3.0







Hello all, 

        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. 

void sendEvent (int eventType, Event event, boolean send) { 
        Display display = getDisplay (); 
        if (eventTable == null && !display.filters (eventType)) { 
                return; 
        } 
        if (event == null) event = new Event (); 
        event.type = eventType; 
        event.display = display; 
        event.widget = this; 
        if (event.time == 0) { 
                event.time = display.getLastEventTime (); 
        } 
        if (send) { 
                sendEvent (event); 
        } else { 
                display.postEvent (event); 
        } 
} 

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. 

Thank you for your time in advance. 


-------------------------------------------------------------------------
Kind Regards,

Michael D. Elder
Rational Studio / J2EE Tools Development 
IBM RTP Lab
Ext: (919) 543-8356
T/L:  441-8356
mdelder@xxxxxxxxxx