Giulio Bernardi wrote:
Hi,
even looking at sources of various interfaces, I cannot really
understand how the interface should behave in respect to lcl when
handling keyboard events.
I'll try to clear some things. (and I'll speak for gtk since I recently
dived into it)
Let's look at keydown case:
(note: for "event considered handled" I mean the interface should tell
native widgetset that the event has been handled, that is, widgetset
doesn't handle/propagate further that message)
a key has been pressed.
Interface sends a CN_(SYS)KEYDOWN message
If lcl handles it (result<>0), interface should consider the event
handled and stop there (no xx_char or utf8keypress). right?
Yes
if lcl doesn't handle it, interface should proceed:
Yes
if key was changed it has to stop. right? the event has to be
considered handled?
Ehm.. Ive seen 2 situations. When the key is changed to 0 it stops.
When the key is set to another key, it depends. Iirc only a LM_char (and
maybe inftutfchar) passes this key to the widgetset.
Does the interface have to send a LM_(SYS)KEYDOWN message then?
the gtk interface doesn't send them
does it
have to do the same checks it did for CN_KEYDOWN (handled by lcl/key
changed etc)?
Yes
If the key is not "special" (like arrows, ins, canc, return, backspace
and so on) interface sends an utf8 char via IntUTF8KeyPress.
Maybe phrase it different, when the keypress represents a character, it
is sent via IntUTF8KeyPress
if lcl handles it (result=true) interface should consider the event
handled and stop there (no xx_char). right?
Yes
if lcl doesn't handle it:
check if key was changed, if so stop. the event has to be considered
handled?
Not sure. IIRC it continues.
if the key is an ascii char (does ascii mean "<=127" or does it mean
"any non-special key that can be contained in a byte according to
current locale, like iso-something"?)
IIRC, the latter
interface should send a
CN_(SYS)CHAR. right? Does it have to do same checks as KEYDOWN case? And
should it send a LM_(SYS)CHAR after that? And again, should it check for
all these things?
Yes, Yes, Yes
Moreover:
if key is a unicode character that isn't an ascii character (<=127),
should its keycode be VK_UNKNOWN?
Now you mixup VK_xxx keycodes and characters. They are almost totaly
unrelated, except that on a roman keyboard layout VK_A..VK_Z,VK_0..VK_9
happens to correspond to keys Aa..Zz,0..9
> But doing so, xx_(SYS)KEYDOWN/KEYUP
would be useless since we pass VK_UNKNOWN as keycode: so keydown/keyup
should not be sent; so if I type an accented letter, being
it not ascii, OnKeyDown/OnKeyUp events won't fire? It's a bit strange...
Therefore we always send a keycode of the *key* pressed.
However, I recently fixed parts of this. For keyboard layouts where 3 or
more chars per key exists, it could happen that a VK_UNKNOWN was sent.
Also something else....
If you compose a char through a dead key and a normal key, the current
gtk1 implementation doesn't get a notice from the dead key and the old
situation reports a VK_UNKNOWN and the current situation wont send a
keydown/up for the combination, since it cannot determine the key
pressed from the resulting char
I have some ideas to "fix" this, but not yet implemented.
The gtk2 implementation currently uses the same implementation as gtk1,
but I plan to fix that soon.
As you can see, I'm a little bit confused :)
Most thing you already figured out :)
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
