[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Newsgroup Home]
|
[news.eclipse.platform.swt] Re: KeyEvent.keyCode
|
We're not hiding any information but it's another field that has to be
available and right on every platform. For example, when the user is typing
in Japanese characters in the IME on Linux, the raw unaffected keycodes are
simply not available.
Try this:
int key = event.character;
if (key == 0) {
key = event.keyCode;
} else {
if (0 <= key && key <= 0x1F) {
if ((event.stateMask & SWT.CTRL) != 0) {
key += 0x40;
}
} else {
if ('a' <= key && key <= 'z') {
key -= 'a' - 'A';
}
}
}
int mods = event.stateMask & SWT.MODIFIER_MASK;
int accelerator = mods + key;
"Stephen" <stephen.goldbaum@xxxxxxxxxx> wrote in message
news:badr3l$pna$1@xxxxxxxxxxxxxxxx
> OK, that's a point. However, I'm not concerned with international
> keyboards. In any case, I don't see how providing the keyCode is in any
> way dangerous. It's just another bit of information that may or may not
> be useful, depending on your application. I certainly don't see why you'd
> want to hide it from us.
>
> I'm trying to mimic JFace Action accelerator behavior for cases when the
> menubar isn't present (and toolbar in the future). Unfortunately, setting
> the Action's accelerator to "Ctrl+T" (via the convert methods) gets a
> value of 262228 (SWT.CTRL|'t'). This value is in no way related to the
> values in the fields of the associated KeyEvent. In fact, the only way I
> could get the Action accelerator to match the state of the KeyEvent was to
> set the accelerator to (SWT.CTRL|''). Unfortunately, this relies on
> checking the stateMask for SWT.CTRL, thus presenting the same problem you
> mentioned previously. Am I missing something? Do you have any other
> suggestions for this?
>
> Thanks,
> -Stephen
>
>
> Steve Northover wrote:
>
> > Yes, this is portable and works the same on all platforms (please enter
a
> > bug report when it doesn').
>
> > Looking for a state mask and key code combination does not work well on
> > international keyboards. For example, on German Windows, to type an
'@',
> > the user presses Strg+'Q' or Ctrl+Alt+'Q'. The Ctrl key is down, but no
> > control character is generated.
>
> > /**
> > * depending on the event, the character represented by the key
> > * that was typed. This is the final character that results
> > * after all modifiers have been applied. For example, when the
> > * user types Ctrl+A, the character value is 0x01 (NUL). It is
> > * important that applications do not attempt to modify the character
> > * value based on a stateMask (such as SWT.CTRL) or the resulting
> > * character will not be correct.
> > */
> > public char character;
>
>
>
> > "Stephen" <stephen.goldbaum@xxxxxxxxxx> wrote in message
> > news:ba3hrs$5r2$1@xxxxxxxxxxxxxxxx
> > > Why is KeyEvent.keyCode only used for modifiers? Leaving this field 0
for
> > > alpha keys makes it very difficult to detect key combinations. For
> > > example Ctrl+a generates an event with
> > >
> > > event.character = 0x0001 (whereas 'a' is 0x0101)
> > > event.keyCode = 0x0
> > > event.stateMask = 0x1000000
> > >
> > > So the only way to detect a Ctrl+a is to map it to '^A' (at least on
> > > Windows). Beside being a lot of work, I doubt that this is
cross-platform
> > > compatible. At least providing the keyCode gives us a fighting
chance.
> > >
>
>
>
>
>