Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 322606

Summary:	Provide Event.keyLocation in RWT (added in SWT 3.6)
Product:	[RT] RAP	Reporter:	Elias Volanakis <elias>
Component:	RWT	Assignee:	Project Inbox <rap-inbox>
Status:	NEW ---	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	b.muskalla
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Windows Vista
Whiteboard:

Description Elias Volanakis

2010-08-12 20:44:12 EDT

Since SWT 3.6 there is an Event.keyLocation field. RWT is missing that field. 

	/**
	 * depending on the event, the location of key specified by the 
	 * keyCode or character. The possible values for this field are 
	 * <code>SWT.LEFT</code>, <code>SWT.RIGHT</code>, <code>SWT.KEYPAD</code>,
	 * or <code>SWT.NONE</code> representing the main keyboard area.
	 * <p>
	 * The location field can be used to differentiate key events that have 
	 * the same key code and character but are generated by different keys 
	 * in the keyboard. For example, a key down event with the key code equals
	 * to SWT.SHIFT can be generated by the left and the right shift keys in the 
	 * keyboard. The location field can only be used to determine the location 
	 * of the key code or character in the current event. It does not 
	 * include information about the location of modifiers in state
	 * mask.
	 * </p>
	 * 
	 * @see org.eclipse.swt.SWT#LEFT
	 * @see org.eclipse.swt.SWT#RIGHT
	 * @see org.eclipse.swt.SWT#KEYPAD
	 * 
	 * @since 3.6
	 */
	public int keyLocation;

I realize that adding the field is just the first step. Propably RWT needs to be revied at the places where Events are generated so that the information is actually filled correctly.

(Note: This is a nice to have feature for us. I'm filing it as an enhancement)

Comment 1 Ivan Furnadjiev

2010-08-13 04:31:10 EDT

I doubt that it's possible to properly implement this, as there is no such information in browser dom event.

Comment 2 Rüdiger Herrmann

2010-08-13 14:45:38 EDT

I could imagine to implement this feature with "hardcoded" values like so: 
* usualley keyLocation is NONE, 
* for SHIFT, the keyLocation would always be LEFT
* for numeric keys, the keyLocation would always be NONE as if there was no keypad
* etc.

Comment 3 Benjamin Muskalla

2010-08-13 14:56:20 EDT

DOM3 API already supports keyLocations (see http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/events.html#Events-KeyboardEvent-keylocation )

I think using defaults for all other browsers would be sufficient.