Bugzilla – Full Text Bug Listing
| Summary: | Can't assign command to Ctrl+Backspace | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Dani Megert <daniel_megert> | ||||||||
| Component: | SWT | Assignee: | Steve Northover <snorthov> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | critical | ||||||||||
| Priority: | P3 | CC: | csmclaren, douglas.pollock, eclipse.sprigogin, jcompagner, Jon.Rabone, kai-uwe_maetzel, Kelsey.grant, kwester, lbreisacher, nikolaymetchev, oyvind.harboe, spaced, tonny.madsen, wizardofbeans | ||||||||
| Version: | 3.0 | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | |||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 43140 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Dani Megert
I'm seeing the same thing. I'm on WinXP Pro. I have build 200308281813. Oh, and I have an ordinary US keyboard. some here. Windows 2000 and normal UK keyboard. oh and Ctrl+Enter seems to be thought of as Ctrl+J Eclipse seems to override the default locale for the JVM when I run the
following code:
--------------------
package a;
import java.util.Locale;
public class A
{
public static void main(String[] args)
{
System.out.println(Locale.getDefault());
}
}
--------------------------
I always get en_US despite my locale being en_GB
The locale problem is not related. Please file a separate bug. The problem is that key events from SWT appear differently on Windows XP and Linux-GTK. For example, "Ctrl+Backspace" on the two systems is: Windows XP - keyCode=0x08, character=0x7F DEL Linux-GTK - keyCode=0x08, character=0x08 '\b' And "Ctrl+Enter" is: Windows XP - keyCode=0x0D, character=0x0A '\n' Linux-GTK - keyCode=0x0D, character=0x0D '\r' Created attachment 5996 [details]
Patch for KeySupport
This still needs testing on Linux-GTK. It appears to work for every key
combination I can dream up on Windows XP. The patch is meant to be applied to
KeySupport in the org.eclipse.ui.workbench project.
It looks good on Linux-GTK. Unexpected behaviour can still be seen on the following key strokes: - "Ctrl+Break" sends "Ctrl+C" twice on Windows XP. - "Ctrl+Enter" (using the enter on the right keypad) sends 0x00 and 0x00 on Linux-GTK. - "Ctrl+Shift+2" sends 0x00 and 0x00 on Windows XP (and Linux-GTK, as long as it's not on an entry widget -- see Bug 42009) chris: review/apply. doug your patch looks good, though i fear we are making amends at our level for mistakes in swt. before we commit anything, i want to move this bug to steve northover. steve: i am attaching a wad for you, a single static method to convert an SWT event to an SWT accelerator representation. you can see doug has done some extra mangling here. can you confirm that the difference between platforms is intentional? furthermore, swt does not support the num-pad-enter key, any reason why? Created attachment 5999 [details]
convertEventToAccelerator.java
*** Bug 42358 has been marked as a duplicate of this bug. *** *** Bug 42547 has been marked as a duplicate of this bug. *** *** Bug 42756 has been marked as a duplicate of this bug. *** *** Bug 42890 has been marked as a duplicate of this bug. *** *** Bug 42932 has been marked as a duplicate of this bug. *** moving to critical because of all the dups. and the nice, fat cc: list as well.. *** Bug 43002 has been marked as a duplicate of this bug. *** Created attachment 6089 [details]
Patch to KeySupport
More hacking to fix the additional problem seen in 43002. Events of the
SWT.Traverse type have different properties with the SWT.CTRL state mask than
those with the SWT.KeyDown type.
Note: this bug seems to be a duplicate of 9794. Events are giving inconsistent character and keyCode between operating systems and between event types. From Bug 43002, on "Ctrl+Tab": key down - character=0x09, keyCode=0x09 traverse - character=0x09, keyCode=0x00 Comment on attachment 5996 [details]
Patch for KeySupport
The newer patch supercedes this one.
*** Bug 42802 has been marked as a duplicate of this bug. *** While verifying the fix, make sure that "Ctrl+Return" and "Ctrl+M" are viewed differently by KeySupport (Bug 42802). It is not just that CTRL-M is also mapped to CTRL-ENTER Because if i remove CTRL-M as the maximize editor (map it to CTRL-SHIFT-N or something like that) Then suddenly CTRL-ENTER is Incremental Find!!! I've seen Ctrl+Enter get mapped to Ctrl+J, Ctrl+M or Ctrl+Enter -- depending on build. It depends which version of KeySupport you have, your locale, and your operating environment (i.e., platform, operating system, etc.) My Ibuild: 20030917 My locale settings: user.country=NL user.language=nl user.timezone=Europe/Berlin user.variant= But remember: In this configuration CTRL-Enter was first mapped to CTRL-M but when i removed that CTRL-M it suddenly mapped to CTRL-J (which is java editor specific) If i also remap that one (CTRL-J to CTRL-[) CTRL-ENTER finally doesn't do anything at default.. Can you comment re: Bug 42035? Are the key code and character values now consistent across operating systems? Thanks. Working on it. Despite the fact that this is "correct Windows platform behavior", it's also not portable. I'm looking into fixing Windows. Fixed > 20030923 *** Bug 43140 has been marked as a duplicate of this bug. *** *** Bug 43785 has been marked as a duplicate of this bug. *** *** Bug 44114 has been marked as a duplicate of this bug. *** |