Community
Participate
Working Groups
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.
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.
This should be fixed.
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.
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?
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.
I fixed the Motif problem > 20020711. KR, if you determine there is nothing else to do, please close this PR.
Sorry, I meant Shift+Alt+Z, not Ctrl+Alt+Z.
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?
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.
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.
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.
Created attachment 1767 [details] Sample code for filtering key strokes
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.
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.
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.
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.