Re: Firing a #buttonPressed event *after* the key has been processed

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: Firing a #buttonPressed event *after* the key has been processed

Steve Waring-2
(Crossposted to c.l.s.d)

Hi Dean,
    I've done something like this recently and the trick was to let Dolphin
and windows process the events, and then do what you need to do.
The two presenter methods I came up with are;

onKeyTyped: aKeyEvent
   super onKeyTyped: aKeyEvent.
    self onCaretMoved.

onKeyPressed: aKeyEvent
   | keyCode |
   keyCode := aKeyEvent code.
   super onKeyPressed: aKeyEvent.
   ((Array with: VK_LEFT with: VK_RIGHT with: VK_DOWN with: VK_UP) includes:
        ifTrue: [self onCaretMoved].

Unfortunately windows splits keystrokes into two categories; "system", and
"non-system", and hooking into the two events was the only way I could find
out if the cursor had moved due to navigation keys or normal typing, after
either the character had appeared, and/or the cursor position had been
updated. You may also need to watch for a mouse click event, but that wasnt
necessary for what I needed.

BTW #onKeyTyped: needs to return something; there is a method comment
explaining this somewhere, but I couldnt find it in a quick look.

Hope this helps,
"Dean Powell" <[hidden email]> wrote in message

> A second quick question:
> I've been messing around with a text editor-type application, and one of
> the things I want to do is list the current caret position in a status box
> at the bottom.  Unfortunately, the #onKeyPressed event seems only to fire
> before the key event has been processed.  This means that I can tell where
> the cursor just came from, but not where it will be after the caret has
> been moved.
> What is the mechanism for querying a RichTextEdit's current caret position
> immediately after a key (cursor or otherwise) has been completely
> processed?
> Thanks for any info.
> Regards,
> Dean Powell