Giulio Bernardi wrote: > 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.
I haven't looked at the carbon interface lately. I also din't look at the keyhandling. THat was still a todo. > 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 > 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? You can also send it to me (or one fo the other devels) > 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, Not really. there are only a few specific codes. > 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 ? > 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. > 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. For mac, it is imo pressy straightforward, simply map all mac VKcodes to win32 VKcodes. That can be done in one bytearray of byte. > 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. Forget the raw keycodes, they are useless. > 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, Please have a look at how it is done for the gtk codes. That is a way more difficult than for mac. Marc _________________________________________________________________ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
