Thank you for your answer.
The reason why I was asking these things is that I came back home (I study
in another city) where I have an old PowerMac covered with dust (I'm not a
mac user, but it is there in a corner of my room).
So I started studying some carbon docs and I was trying to fix carbon
keyboard handling, which didn't work very well.
What were the problems with mac keyboard handling?
The raw keycode that carbon reports is keyboard specific.
I mean, if we consider a QWERTY keyboard and an AZERTY one, keycode(Q) of
first one = keycode(A) of second one: that is, keycode identifies the
physical key in that position on the keyboard, so it isn't possible to map a
raw mac keycode to, say, VK_A.
Moreover, it didn't recognize KeyDown/KeyUp when a modifier key (shift,
command and so on) was pressed.
A more in-depth explanations of the ways I solved the problem can be found
in comments inside the code.
Is it okay if I send a patch to the list?
Moreover, I have to add a couple of notes:
> 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
It wasn't clear to me when a key represents a character, so I thought that
LCL should try to be the more compatible with Delphi as possible, and since
OnKeyDown/OnChar/OnKeyUp events in Windows are triggered by
WM_KEYDOWN/WM_CHAR/WM_KEYUP messages, I traced the win32 interface to see
when Windows sent those messages.
As a result, I updated the wiki page Vincent pointed me to:
http://wiki.lazarus.freepascal.org/LCL_Key_Handling
I hope I did the right thing.
Next note:
> 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.
Here another problem arises.
In win32, some keys are "well known" and virtual keycodes do exist (VK_A,
VK_RETURN, and so on). Other keys are keyboard dependant, so if I hit the
"egrave" key on my italian keyboard, the keycode that Windows reports in
WM_KEYDOWN/WM_KEYUP won't be the same as the one caused by hitting "egrave"
key on a french keyboard: we could say that keycodes in this case are
meaningless, it's better to work with chars or utf8 chars later.
So one solution, if we are not on win32, would be to just pass the raw
platform-specific keycode in xx_KEYDOWN/KEYUP, since a mapping to a VK_ code
could not be done.
But this can be dangerous.
Consider this (real) example: on my mac keyboard, the raw mac keycode for
"egrave" is 33. This happens to be the same value as VK_PRIOR. If I just
passed the raw mac keycode as a virtual keycode in xx_KEYDOWN/KEYUP, LCL
would have thought that pagedown key was hit.
In win32, keycodes from $BA to $F5 are used for keys like "egrave", so no
collision happens. In carbon interface, I chosed to send $E8 as virtual key
code when no mapping is possible ($E8 is, according to Microsoft docs,
unused).
This way, KeyCode will be useless (as it already was) but at least
OnKeyDown/OnKeyUp events will be triggered,
bye,
Giulio
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
