Bug 21268 - StyledText - Ctrl+Shift+J inserts line
Summary: StyledText - Ctrl+Shift+J inserts line
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 2.0.1   Edit
Assignee: Knut Radloff CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-07-05 15:01 EDT by Nick Edgar CLA
Modified: 2002-08-21 15:48 EDT (History)
1 user (show)

See Also:


Attachments
Sample code for filtering key strokes (1.20 KB, text/plain)
2002-07-30 12:38 EDT, Knut Radloff CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Edgar CLA 2002-07-05 15:01:50 EDT
R2.0 build

- open a text editor
- type some text
- position the cursor in the middle of the text
- type Ctrl+Shift+J
- it has the same effect has hitting Enter

- try Ctrl+Shift+I
- it inserts a tab

This is apparently due to the following code in StyledText.handleKey(Event):

	if (action == SWT.NULL) {
		// ignore anything below SPACE and ignore DEL
		if (event.character > 31 && 
			event.character != SWT.DEL && event.stateMask != 
SWT.ALT || 
		    event.character == SWT.CR || event.character == SWT.LF || 
		    event.character == TAB) {
			doContent(event.character);
		}
	}

Note that it does not check the stateMask.  In the case of Ctrl+Shift+J, 
event.character is 10 (SWT.LF).

I also tried Ctrl+Shift+M, but this simply beeps, and does not even reach this 
condition.
Comment 1 Nick Edgar CLA 2002-07-05 15:04:35 EDT
Also try Ctrl+ALT+Z.  It inserts a Z.  Likewise for any letter that is not 
used as a menu mnemonic.  The condition above should check whether the SWT.ALT 
bit is set, not whether the stateMask is == SWT.ALT.

Comment 2 Lynne Kues CLA 2002-07-08 14:46:35 EDT
This should be fixed.
Comment 3 Knut Radloff CLA 2002-07-10 13:21:16 EDT
Ctrl Z (and Ctrl+Alt Z) are translated to decimal 26 on my system and are thus 
already filtered out as a non-printable character.
On Linux/Motif any Ctrl and Ctrl+Alt combination results in the character being 
inserted in the text. 
Did you see the Ctrl+Alt behavior on a Win2k system with Canadian locale? I can 
not reproduce this.
Comment 4 Steve Northover CLA 2002-07-11 12:54:40 EDT
This bug was introduced on Motif in R2.0 to fix a case where certain control 
key combinations were giving random values.  For example, Ctrl+/ had an invalid 
character value but the correct keysym.  Grant fixed the original bug, he is on 
vacation so I don't have more details.

So, Ctrl+J should not insert a J.  If I fix this, is this PR fixed also?
Comment 5 Knut Radloff CLA 2002-07-11 13:33:08 EDT
Fixing the Motif bug would fix the incorrect behavior I see on Motif.
However, Nick claims he is also seeing this on Win2k. I'll have to reproduce 
this on Win2k. I'll be in OTT next week. Nick can show me then.
Comment 6 Steve Northover CLA 2002-07-11 14:40:35 EDT
I fixed the Motif problem > 20020711.  KR, if you determine there is nothing 
else to do, please close this PR.
Comment 7 Nick Edgar CLA 2002-07-11 16:40:48 EDT
Sorry, I meant Shift+Alt+Z, not Ctrl+Alt+Z.
Comment 8 Knut Radloff CLA 2002-07-12 11:54:38 EDT
Of course. Fixed the Shift+Alt problem by checking the state mask for ALT bit.

I still believe the special Ctrl key combinations for CR, LF and TAB is a 
feature and should not be changed. Can you live with that?
Comment 9 Nick Edgar CLA 2002-07-12 16:06:18 EDT
I'm not sure what the benefit is of this feature.
But as long as Ctrl+Shift+J and Alt+Shift+Z don't insert characters, I'm happy.
Comment 10 Knut Radloff CLA 2002-07-15 13:45:46 EDT
The Ctrl sequences is platform behavior that we shouldn't filter out without a 
good reason. Applications that don't want this feature can filter out the 
appropriate key strokes using a VerifyKey listener.
Comment 11 Knut Radloff CLA 2002-07-30 12:36:37 EDT
This fix causes the bugs noted as duplicates in bug 20953, can not enter Alt Gr 
key combinations. Alt Gr is translated to Ctrl + Alt on Windows which we now 
filter out.
We need to reconsider whether it's a good idea for StyledText to make 
assumptions about what constitutes valid text and what does not. This may 
depend on the application and perhaps the application should filter unwanted 
key strokes.
Once we filter out key strokes we can not change the behavior back later (after 
a release).

An argument for both sides, filtering in StyledText vs. letting the app do the 
filtering, is the fact that ports to other platforms (e.g., Mac OS X) may 
produce valid characters with a key combination that we filter out. 
The Mac keyboard has a concept similar to Alt Gr to produce some characters. I 
don't know what this key is mapped to, if anything, in SWT. It may just produce 
the character with the state mask unused. That is how the Alt Gr key works on 
Linux.
One could argue that StyledText shouldn't do any filtering because different 
ports may produce different key events and filtering may prevent valid key 
strokes. Or one could argue that StyledText should produce consistent key input 
results on all platforms and should deal with whatever platform differences 
there may be.

I'm attaching code that shows how you could filter out the Ctrl and Alt key 
combinations that you don't want (but let Ctrl+Alt = Alt Gr through). Let us 
know what you think about filtering responsibility in light of bug 20953.
Comment 12 Knut Radloff CLA 2002-07-30 12:38:01 EDT
Created attachment 1767 [details]
Sample code for filtering key strokes
Comment 13 Nick Edgar CLA 2002-07-30 14:53:13 EDT
The application should not have to add key filtering code.
Bug 20952 is more serious than this one, so either we should follow Steve's 
recommendation in 20952 (just remove the check) or push down the check you 
attached above into StyledText.
Comment 14 Steve Northover CLA 2002-08-06 16:42:00 EDT
The bug number should read 20953.  The control key fix for Linux as described 
in this PR is now fixed in R2.0.1 as well as HEAD.
Comment 15 Veronika Irvine CLA 2002-08-21 15:40:17 EDT
Can someone confirm that this bug is really fixed in 2.0.1?
I see no updates to StyledText in 2.0.1 and I see no update comments in 2.0.1 
which reference this PR number.
Comment 16 Knut Radloff CLA 2002-08-21 15:48:49 EDT
This bug was really two separate ones.
Only the Motif Ctrl character bug is fixed in the 2.0.1 stream.
The StyledText fix for the Shift+Alt bug I mention in my note from 7/22 is only 
in the 2.1 stream.