Bugzilla – Full Text Bug Listing
| Summary: | StyledText - tilde problem with french keyboard (2000,NT,XP) on R2.0 | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Lautier Teva <teva.lautier> |
| Component: | SWT | Assignee: | Knut Radloff <knut_radloff> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | P1 | CC: | andre_weinand, boris, imouslim, spamfaenger, uwe.pyka, walter.weinmann |
| Version: | 1.0 | ||
| Target Milestone: | 2.1 M4 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 21886 | ||
|
Description
Lautier Teva
Moving to SWT Build 20020723 I believe that this is the same issue as Bug 21886. However I cannot replicate it on 20020723. Could you please give some steps in replicating this problem? I have replicated the problem on both the Java Editor and the Text Editor in 20020723. This is not a general problem but one specifically with the editors. Here is the ingredients:
1- a Windows 2K with the latest update available from Mr Bill.
2- a french keyboard (a basic one)
3- a Fresh install of eclipse I will use the 20020723.
4- launch eclipse, and switch to java perspective
5- create a new java project, then a java class
6- all the chars with the combination alt-gr+* doesn't work except tild '~'
and '`' (these 2 chars apears after pressing the space key)
those chars are: #{[|\^@]}.
7- finally I replace the org.eclipse.swt.win32_2.0.0 and org.eclipse.swt_2.0.0
with those from R2.0, launch eclipse again: it seems that the problem was
solved!
8- should look around SWT
The problem is in StyledText. As I see it, we must be testing the Ctrl+Alt
flags before looking at the character (which is fatal on a Windows platform
with an Alt+Gr key). Note that on other platforms such as X/Motif, the
Ctrl+Alt keys are not down when the Alt+Gr key is pressed.
So, the right thing to do everywhere is ignore the flags when a character is
pressed.
The native text widget works and the following example code works:
public static void main (String [] args) {
Display display = new Display ();
Shell shell = new Shell (display);
Listener listener = new Listener() {
public void handleEvent(Event e) {
String string = e.type == SWT.KeyDown ? "DOWN" : "UP ";
string += ": stateMask=0x" + Integer.toHexString
(e.stateMask);
if ((e.stateMask & SWT.CTRL) != 0) string += " CTRL";
if ((e.stateMask & SWT.ALT) != 0) string += " ALT";
if ((e.stateMask & SWT.SHIFT) != 0) string += " SHIFT";
string += ", keyCode=0x" + Integer.toHexString
(e.keyCode);
string += ", character=0x" + Integer.toHexString
(e.character);
switch (e.character) {
case 0: string += " '\\0'";
break;
case SWT.BS: string += " '\\b'"; break;
case SWT.CR: string += " '\\r'"; break;
case SWT.DEL: string += " DEL"; break;
case SWT.ESC: string += " ESC"; break;
case SWT.LF: string += " '\\n'"; break;
case SWT.TAB: string += " '\\t'"; break;
default: string += " '" +
e.character +"'"; break;
}
System.out.println (string);
}
};
shell.addListener(SWT.KeyDown, listener);
shell.addListener(SWT.KeyUp, listener);
shell.setSize (200, 200);
shell.open ();
while (!shell.isDisposed ()) {
if (!display.readAndDispatch ()) display.sleep ();
}
display.dispose ();
}
*** Bug 21887 has been marked as a duplicate of this bug. *** I have a test case that demonstrates this:
Note that you can type { in the regular text but not in the StyledText.
import org.eclipse.swt.SWT;
import org.eclipse.swt.custom.StyledText;
import org.eclipse.swt.layout.GridData;
import org.eclipse.swt.layout.GridLayout;
import org.eclipse.swt.widgets.*;
/**
* @author Tod
*
* To change this generated comment edit the template variable "typecomment":
* Window>Preferences>Java>Templates.
*/
public class MultipleTextTest {
public static void main(String[] args) {
Display display = new Display ();
Shell shell = new Shell (display);
Composite basicInfoComposite = new Composite(shell, SWT.BORDER);
GridLayout layout = new GridLayout();
basicInfoComposite.setLayout(layout);
GridData data = new GridData(GridData.FILL_BOTH);
data.grabExcessHorizontalSpace = true;
basicInfoComposite.setLayoutData(data);
// path value label
Text pathValueText = new Text(basicInfoComposite, SWT.WRAP | SWT.MULTI);
StyledText styled = new StyledText(basicInfoComposite,SWT.MULTI);
GridData styledData = new GridData();
styledData.widthHint = 200;
styledData.heightHint = 200;
styled.setLayoutData(styledData);
basicInfoComposite.setVisible(true);
basicInfoComposite.pack(true);
shell.setSize (400,400);
shell.open ();
while (!shell.isDisposed ()) {
if (!display.readAndDispatch ()) display.sleep ();
}
display.dispose ();
}
}
*** Bug 21886 has been marked as a duplicate of this bug. *** *** Bug 21753 has been marked as a duplicate of this bug. *** We can't ignore the stateMask because of bug 21268. That bug requested filtering out any Ctrl and Alt key combinations to avoid inserting characters for unused mnemonic and shortcut key strokes. It seems that we should filter out any Ctrl and Alt key combinations except for Ctrl + Alt itself: boolean isCtrlAlt = (event.stateMask & (SWT.ALT | SWT.CTRL)) == 0 || event.stateMask == (SWT.ALT | SWT.CTRL); if (isCtrlAlt && event.character > 31 && event.character != SWT.DEL || event.character == SWT.CR || event.character == SWT.LF || event.character == TAB) { doContent(event.character); } Fixed in > 20020729 Seems like a bad idea to look for Ctrl+Alt, especially as this sequence only happens on Windows ... but I can't think right now what bug will be caused because of it. It seems to me you want to filter out regular key strokes (ie. 'A') when only Alt or Alt+Shift is down. When Ctrl is down, event.character will be a control character (<= 31) unless it was caused by Alt+Gr. This approach will fail if Alt+Gr can ever generate a control character, but I think it never can. You need not change your code but as I said before, there's something bad about looking for Ctrl+Alt. I would just let Alt+<char> enter the character into the widget and avoid the whole issue (ie. remove the check). We filter Ctrl combination because Ctrl + numeric key results in the numeric key, not a control character. I've updated bug 21268 to indicate that filtering key strokes causes problems. It's not clear that letting the application do the filtering, if desired, is the right thing to do either. There are arguments both ways. If we don't filter but the app does and there's some new, weird platform behavior with regards to key events it would force the app to deal with platform specific issues (I'm thinking Mac here). On the other hand there may be apps that want all characters no matter what the state mask is. See bug 21268 for more. SN wants to reopen this, saying "the right thing to do everywhere is ignore the flags when a character is pressed.". See PR26589 for details. This has become an issue on the Mac for entering curly brackets. *** Bug 26589 has been marked as a duplicate of this bug. *** Can't do what SN suggests. We do want to filter out characters in the case where Alt + character was pressed to access a menu mnemonic that does not exist. Otherwise Alt + Z would result in a Z in the text when there is no menu mnemonic for Z. See bug 21268. How do mnemonics work on the Mac? How are they accessed? I am probably not the best person to tell this but I'l try. Mnemonics or keyboard shortcuts on the mac always start with <command> also called <accelerator> (They are marked with a small apple on the key). All key-combos with this flag are purely used as shortcuts. Other modifiers, like <option> (also called <alt>) and <control> are used as modifiers for the entered key if they are used alone. If used together with <command> they are just modifiers for the mnemonic. (Also some, but only some very rare application may diverge from this principle but all in all its set in stone and should not be used differently.) From what Martin writes above and Andre in bug 26589 it seems that we should not filter Alt/Shift-Alt key combinations on the Mac. I would love to get rid of the key filtering magic altogether but then we would reintroduce the mnemonic issue documented in bug 21268 Yes, please don't filter Alt/Shift-Alt key combinations on Mac OS X, otherwise Eclipse is not usable on non-US Mac keyboards. Is it possible to get that fix into tomorrows (I20021126) integration build? GTK: GTK behaves like Windows. Pressing Alt+<character> when there is no mnemonic for that character results in a key event for the character. Also like on Windows, the regular text widget does not insert that character into the text. Motif: The regular text widget does insert characters in the text if there is no mnemonic associated with the Alt+<character> combination. The key sequence is not filtered out. Since we don't want to try and match any given platform behavior we should just fix the case that's broken. However, to simplify the workaround we should just take out any filtering code on the Mac. Fixed in > 20021125. Took out filtering when running on OSX/Carbon. |