[news.eclipse.platform.swt] Re: KeyEvent.keyCode

[stephen.goldbaum@xxxxxxxxxx (Stephen)]

Ahh.  So I found some docs on how the Ctrl key maps ASCII values (I still
haven't found anything official, though).  Maybe Action could add a couple
of methods like, 
  public boolean isAccelerator(Event e)
  public static int convertAccelorator(KeyEvent)

that does what you've described.

Thanks,
Stephen

Steve Northover wrote:

> 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.
> > > >
> >
> >
> >
> >
> >