Giulio Bernardi wrote:
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".
[...]
OK, thanks for clearing that. I only recently came across them while
restructuring the gtk keyboard handling. I had a quick scan and
bookmarked them for later use.
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...
That looks like the same way as I create the VKeys for gtk. For every
(raw)keycode I query the unshift/shift/AltGr/altgr+shift values and
based on those values I lookup the VKey.
Have a look at gtkproc.inc InitKeyboardTables.
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.
The unicode char is useless for reporting the VKey in up/down events. It
gets messy when chars can be made by more than one key, or are composed.
Been there, tried that and it didn't work.
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.
I won't assume that.
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)
That is similar to gtk.
> 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
I think it should report the VKey for "["
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.
Hmm... I note the capslock key on that layout. I've read somewhere that
macs don't have a numlock. Is that still the case (I can't check, since
I hooked a pc keyboard to my mini)
Speaking about Windows VKs, as said there:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/UserInput/VirtualKeyCodes.asp
Somehow I know that table :)
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).
From the picture you gave me I disn't expect different
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).
:) Even on other languages, it is a question if the VK_Q represents a
"Q". This is only valid for roman layouts.
For the gtk mappings, I tried to match the VK_OEM keys to the notes MS
gave themselves on the VirtualKeyCodes page.
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).
I still think it is possible :) But I have to admit, i've not looked at
all the available functions. (But I'll do that as soon as I start on
gtk2-carbon)
> 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.
At least on gtk, there are keypresses reported of characters which get
composed by some keystrokes (or through IME). In those cases only the
char is reported (so in exceptional cases only a char is send)
> 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).
Look for the algo I used.
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).
The general idea is n't differen from the old situation. The latest code
isn't even comitted yet, but it contains far less "tables"
(for the raw work in progress, see
http://lazarus.dommelstein.nl/lcl/interfaces/gtk/gtkproc.inc )
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.
Indeed. As I said, I only had a quickscan of the mentioned urls, and
there I saw raw-codes and virtual-codes reported. So I wrongly concludes
that the virtual-codes were constant. (I still winder why there are 2
different non-constant codes)
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.)
Not really a dummy, we assing it on startup and try to keep them the
same all times :)
Marc
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
