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

[Michael Elder <mdelder@xxxxxxxxxx>]

Michael, (and) Douglas,

        Thank
you for your quick replies!

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

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

Michael Van Meekeren <Michael_Van_Meekeren@xxxxxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx

06/23/2004 10:50 AM

Please respond to
platform-ui-dev

To	platform-ui-dev@xxxxxxxxxxx
cc
Subject	Re: [platform-ui-dev] Change in the ordering of key events from Eclipse 2.1.x to Eclipse 3.0

Michael, 

I've just pulled the following from the "Eclipse 3.0 Porting Guide",
I think it should answer your questions: 


SWT.KeyDown events 
In 3.0 key down events are reported before the work is done in the OS.
This is much earlier than it was prior to 3.0. This change was made to
support key bindings in Eclipse which necessitates intercepting key events
before any widget had a chance to process the character. Consequences of
this change are visible to code that handles low-level SWT.KeyDown events
directly. For example, it means that when a listener on a Text widget receives
a key down event, the widget's content (getText()) will not yet include
the key just typed (it would have prior to 3.0). The recommended way to
get the full text from the widget including the current key is to handle
the higher-level SWT.Modify or SWT.Verify events rather than the low-level
SWT.KeyDown event; code that does it this way is unaffected by this change.

/michael

Michael Elder <mdelder@xxxxxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx

06/23/2004 10:11 AM

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