Uhm... sorry but I need to be more verbose than what I already am :)
In short: virtual keycodes for mac do not exist.
The articles you reported might be misleading. I'll explain.
On Macs, there is not a "raw scancode" and a "virtual keycode". Or better,
if they are two different thing, there is no API to obtain both.
The lowest level keyboard thing you can obtain is the "key code" as
returned by kEventParamKeyCode parameter in kEventRawKeyDown/Repeat/Up
event.
This actually is the "Virtual Key Code" that the two articles you reported
talk about, even if it is not so "virtual" but looks very "raw".
How can I say that?
Well, I think that the guy that wrote the first article only used US
keyboards :)
(http://rentzsch.com/macosx/virtualKeyCodes)
In the same page, at the end, Bruno Fernandes says that Virtual key codes
are not the same across keyboards layouts, and that Mac OS lacks any API for
VK translations across layouts.
In fact, at the very end of the page, there is a link to an article by
Blake Seely that replies to that article (Blake Seely explains it all,
that's where I started from to fix the carbon key handling).
http://blakeseely.com/blog/archives/2006/09/26/virtual-keys/
Other "proofs":
In the first article (rentzsch), the writer points to Macintosh ToolBox
Essentials PDF. If you go to page 87, as he says, you can see the virtual
key codes for two mac keyboards. But these two mac keyboards are and Apple
Extended Keyboard (US I think) and another one with French layout: look at
QWERTY keys of the US and at AZERTY ones of the French: you'll see that VK
of Q is 0C on US, but this is VK of A on french keyboard.
That is, the "virtual key codes" are not so virtual, since they are relative
to "the first key at the right of tab" instead of "letter Q".
(It's fun that the writer says "Z will have a consistent virtual key code:
6" while looking at the pdf he himself suggests you can see that Z is 6 on
US keyboard while on french one is 0D :P)
I could add another "proof" based on my experience (I have an old mac with
an italian QZERTY keyboard, while all macs from 1999 till now have QWERTY
italian keyboards, IIRC) but I won't write it since I'm writing too much :)
So, I think that now it should be clear that you can't simply map one mac VK
to the windows one with an array, because VK are not even consistent on the
same mac with two different keyboard layout.
That said, is there something a bit higher level we can use?
Well, next step is the character.
Having the (not so virtual) key code, we could obtain the Unicode character
with UCKeyTranslate function, that requires some lines of code to retrieve
the keyboard layout resource and so on...
Last lines of the listing in this page show it:
http://developer.apple.com/qa/qa2005/qa1446.html
However, instead of doing all this stuff, we can receive the unicode
character asking for kEventParamKeyUnicodes parameter in
kEventRawKeyDown/Repeat/Up event, and the "ascii" one asking for
kEventParamKeyMacCharCodes parameter.
But here we have a problem: the Virtual Key Code is too low level, the
character is too high level since we can't intercept arrows, function keys
and so on.
But, it looks like some keys are constant across all keyboards (I think it's
because they are always in the same position on all keyboards), and they are
the "non visual" characters.
So, what I did in carbon interface is:
* try to see if the mac key code is a known non visual one. If it is,
translate to the corresponding windows VK and we're done
* else, get the unicode char and see if there is a good VK_ (that is, if
unicode char is plain "a", its VK will be VK_A, and so on)
> What were the problems with mac keyboard handling?
> The raw keycode that carbon reports is keyboard specific.
Yes, therefor it is a raw keycode :)
> 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.
There fore one should use the mac virtualkeycodes, they are next to the
raw keycode and afaik, they are the same for all macs.
see:
http://rentzsch.com/macosx/virtualKeyCodes
http://classicteck.com/rbarticles/mackeyboard.php
See above.
> Is it okay if I send a patch to the list?
You can also send it to me (or one fo the other devels)
Ok.
[SMALL CUT]
> 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,
Not really. there are only a few specific codes.
Mh.. not so sure they are few. See a little later.
> 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:
The VKcode corresponds to the key, not the text. But where do you have
the egrave key ? Is it located on some other ?
Look at this image:
http://it.wikipedia.org/wiki/Immagine:Qwerty_it.svg
This is the QWERTY Italian keyboard that is used on all PCs and on "newer"
Macs (from the blue-and-white G3 and the first iMac till now IIRC)
As you can see, egrave is on the left of P key. It is where [{ key is
located on US keyboards.
Speaking about Windows VKs, as said there:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/UserInput/VirtualKeyCodes.asp
its VK is VK_OEM_4 = $DB. But if I use a US keyboard, $DB is [{, while on an
italian keyboard, $DB is egrave (I checked it, I pressed egrave on a QWERTY
keyboard on Windows and I received a WM_KEYDOWN with $DB, a WM_CHAR with
egrave character, and a WM_KEYUP with $DB).
That's why I said that OEM keys range between $BA and $F5 (so they are not
only some few specific codes) and that they are "meaningless": it's useless
to check for VK_OEM_4, since it is not like VK_Q that represents "Q" whether
or not Q key is located next to tab (in qwerty) or next to capslock (in
azerty).
So this is the reason why I think that those keycodes simply can't be
translated: i can't translate mac virtual key code for egrave to the windows
one because they are different on the same platform if different layouts are
used (my mac QZERTY keyboard has egrave on "6" key, the mac QWERTY has it
next to "P" key). And other common keys can't be translated for the same
reason (VK of ";" on windows-ita is different from VK of ";" on windows-us,
and the same happens for macs).
> we could say that keycodes in
> this case are meaningless, it's better to work with chars or utf8 chars
> later.
Yes, those keys only send a char/utfchar.
This is the same as in delphi.
Huh? So we don't have to always send a char for key pressed? In previous
mail you said "Therefore we always send a keycode of the *key* pressed.". I
don't understand now.
> 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.
why do you think that ? the raw code is as usefull as any other random
char.
Mapping to delphi compatible vkcodes is possible, and where not at least
keep them always the same. Raw codes are not.
Well, okay, for "raw key codes" i meant "mac virtual key codes". I called
them raw because in my opinion they aren't so virtual (for the reasons I
explained in the beginning of the mail).
Here we agree (if I understand correctly): I try to map them the more as
possible, and when not I always send the same dummy VK ($E8, which isn't
used).
For mac, it is imo pressy straightforward, simply map all mac VKcodes to
win32 VKcodes. That can be done in one bytearray of byte.
See at the beginning of the mail.
Please have a look at how it is done for the gtk codes. That is a way
more difficult than for mac.
I'll look now that you fixed gtk key handling (while fixing carbon I didn't
update my svn and had the old gtk stuff till today). However I think that a
lot of things were due to the fact that I named "raw key codes" the mac
"virtual key codes" (since in my opinion they are a little too "raw" and
less "virtual", compared to windows ones). Now the matter should be clear.
My original mail "only" regarded two things:
* what keys should generate char/utfchar (i made the list on the wiki page)
* what to do with keys that can't be mapped to VKs (if I understood
correctly, we agree that for keys that can't be mapped we send a dummy VK.)
_________________________________________________________________
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
