Bug 4544 - CTRL combination not handled as accelerators when Caps are locked (1FZQDGR)
Summary: CTRL combination not handled as accelerators when Caps are locked (1FZQDGR)
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 2.0   Edit
Hardware: All Linux
: P5 normal (vote)
Target Milestone: ---   Edit
Assignee: Knut Radloff CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-10-11 14:18 EDT by Knut Radloff CLA
Modified: 2002-07-01 15:48 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Knut Radloff CLA 2001-10-11 14:18:40 EDT
When caps lock is on any CTRL key combination results in space being inserted
in the text. Selected text is deleted/replaced with the space.

To reproduce:
1. Turn on caps lock
2. Select text
3. Hit Ctrl+I to indent the text
-> the selection is replaced with a space


NOTES:

LK (8/15/00 11:40:12 AM)
	Document in release notes.

KR (8/15/00 11:44:44 AM)
	This is a SWT bug. Run the test case below. Type some characters, turn caps lock off,
	type CTRL+R. This is handled as an accelerator.
	Turn caps lock on and type CTRL+R again. On Linux a space is inserted, on Windows it
	is still handled as an accelerator.

import com.ibm.swt.*;
import com.ibm.swt.widgets.*;

public class PR_1FZQDGR {
	public static void main(String[] args) {
		Shell shell = new Shell();
		Text text = new Text(shell, SWT.MULTI);
		Menu menuBar = new Menu(shell, SWT.BAR);
		MenuItem item0 = new MenuItem(menuBar, SWT.CASCADE);
		Menu menu = new Menu(menuBar);
		MenuItem item1 = new MenuItem(menu, SWT.PUSH);
		MenuItem item2 = new MenuItem(menu, SWT.PUSH);
		
		item0.setText("item0");
		item0.setMenu(menu);
		shell.setMenuBar(menuBar);
		item1.setText("item1	CTRL + I");
		item1.setAccelerator(SWT.CTRL | 'I');
		item2.setText("item2	CTRL + R");
		item2.setAccelerator(SWT.CTRL | 'R');
		
		Listener listener = new Listener() {
			public void handleEvent(Event e) {
				System.out.println(e.widget);
			}
		};
		item1.addListener(SWT.Selection, listener);
		item2.addListener(SWT.Selection, listener);
		
		text.setBounds(shell.getClientArea());
		shell.open();
		Display display = shell.getDisplay ();
		while (!shell.isDisposed ()) {
			if (!display.readAndDispatch ()) display.sleep ();
		}	
	
	}
}

KR (8/15/00 12:22:41 PM)
	We don't need the fix for VAME 1.2.

	McQ (8/18/2000 12:21:04 PM) -
		Linux applications handle the mapping of "shifted" (i.e. Shift or Caps Lock)
		control character accelerators inconsistantly. I have seen some which behave
		like windows, and some which do not.

		On windows, the platform behavior is to override the "shiftedness" of the 
		key when the control key is pressed. On X, it is not, so applications
		must handle both cases themselves.

		Arguably then, we are providing platform behavior, but this is clearly
		unpleasant. I'll talk to SN about it when he gets back.
		
KR (8/25/00 3:17:23 PM)
	Do you mean that setAccelerator(SWT.CTRL | 'R' | 'r'); should work? It doesn't.

JH (10/4/00 2:44:18 PM)
	Not a bug. Strangely enough, this is platform behavior.

	McQ (10/10/2000 10:01:55 AM) -
		Note: There *is* an issue here. Currently, there is *no* way to hook both
		the shifted and un-shifted version of the accelerator.
Comment 1 DJ Houghton CLA 2001-10-29 16:20:41 EST
PRODUCT VERSION:
LF510/SWT 0.45 Patch 3

Comment 2 Knut Radloff CLA 2002-07-01 15:48:28 EDT
Tested on Linux/Motif. This works now. Accelerators are no longer case 
sensitive.