2014-06-25 8:58 GMT+02:00 Guillermo Polito <[email protected]>:
> There is a problem in the whole keyboard events: they treat keys as > characters and vice versa. And that's not always true: > - the backspace key is a key, but currently the image interprets it as a > character because we only use keypress events in general. > - the shift key is a key, and since current image does not use keyup nor > keydown, we cannot know if JUST a shift is pressed normally. > > > On Wed, Jun 25, 2014 at 8:53 AM, Sven Van Caekenberghe <[email protected]> > wrote: > >> I don't know anything about event handling, but I once had a look at >> Character constants, and found this: >> >> Character class>>#home >> ^ self value: 1 >> >> How about that ?? This is wrong IMHO, ASCII / Unicode value 1 is SOH >> (Start of header), sometimes typed as CTRL-A. And there are other strange >> constants like that there. >> >> On 25 Jun 2014, at 08:42, Tudor Girba <[email protected]> wrote: >> >> > Hi, >> > >> > I am on Windows, using Pharo 3.0, and I am trying to get the >> keybindings to work in Rubric using Windows convention (so, Ctrl instead of >> Cmd as a modifier), >> > >> > It worked reasonably well, but the problem is that somehow Ctrl+a is >> mapped to Ctrl+Home. The problem is not specific to Rubric as I can detect >> the same behavior in the regular PluggableTextMorph. >> > >> > Does anyone have an idea of where the problem comes from? >> > >> > Doru >> > >> > >> > >> > -- >> > www.tudorgirba.com >> > >> > "Every thing has its own flow" >> >> >> > ctrl+a has the same strange behavior as ctrl+d ctrl+a -> ctrl+home ctrl+d -> ctrl+end look at KeyboardEvent>>#hasSpecialCTRLKeyValue I am not exactly sure why it is handled that way. Replace the method with hasSpecialCTRLKeyValue ^ self controlKeyPressed and: [ keyValue <= 26 ] now, ctr+a and ctr+d working as expected. But I don't know about the side-effects. nicolai
