Hi Ralf, Thanks for the links and explanation, this makes is clearer.
So what I can read from this is they the virtual key codes mapped to physical events, and the printable characters are akin to state. Robert. On Thu, Jun 4, 2009 at 3:33 PM, Ralph Kern <usene...@rk-se.de> wrote: > Hi Robert, > > here are the pointers to the MS docu: > > virtual key codes: > > http://msdn.microsoft.com/en-us/library/ms927178.aspx > > MS explanation for their term "virtual key code": > > http://msdn.microsoft.com/en-us/library/ms927175.aspx > > Reference for WM_KEYDOWN (has also links to WM_KEYUP and WM_CHAR in the > "See also" section): > > http://msdn.microsoft.com/en-us/library/aa921842.aspx > > In short: virtual key codes represent the physical keys on the keyboard > (including also mouse buttons) and are used in the KEYUP/KEYDOWN events, > while the CHAR events represent *printable* characters for a text > string. For example, the function key F1 produces KEYDOWN/KEYUP events, > but never generates a CHAR event. > > So there is only one virtual key code for the "a" key, but it can > generate a CHAR event for "a" or "A", depending on the keyboard state > regarding SHIFT, SHIFT-LOCK, CTRL, ... > > I don't know whether these virtual key codes relate to X11 keysyms, > because I have little knowledge of the X11 API. > > regards Ralph > > Robert Osfield schrieb: >> HI Ralf, >> >> Thanks for the info. Just to be clear on language and actions could >> you clarify the following. >> >> By virtual key codes do you mean the raw keycodes? I.e. whether you >> press 'a' or have shift pressed to get 'A' you still get 'a'? Or >> are the WM_CHAR the raw keycodes? >> >> W.r.t key presses/key releases. Are these just from the raw key >> codes? Or the final modified character codes? >> >> Robert. >> >> On Thu, Jun 4, 2009 at 2:43 PM, Ralph Kern <usene...@rk-se.de> wrote: >>> hi, >>> >>> perhaps some input from the MS Windows event API: They differentiate >>> between key press and release events (WM_KEYDOWN/WM_KEYUP) using >>> "virtual key codes" and "typed character" events (WM_CHAR) which is the >>> UTF-16 code of a typo generated because of some key press. >>> >>> The virtual key codes include symbols for SHIFT, CTRL and any other >>> button present on the keyboard. For the WM_CHAR events, there is no >>> notion of press/release. >>> >>> regards Ralph >>> >>> Melchior FRANZ schrieb: >>>> Hi, >>>> >>>> * Robert Osfield -- Thursday 04 June 2009: >>>>> I don't think calling it bug clarifies anything, [...] >>>> I didn't call it a "bug" to clarify anything, but because the current >>>> behaviour is without any doubt broken. Maybe I should have used the >>>> MS euphemism "issue" instead. :-) >>>> >>>> Your examples use the comparatively trivial 'a' and 'A' case. Here clients >>>> can make the assumption that both are on the same physcial key (although >>>> even that is problematic). So, for an aaaAAA sequence you can assume >>>> that with the first 'a' physical key 38 was pressed, and with the third >>>> 'A' the same key was released. >>>> >>>> But take '3' and '#' instead, and a sequence 333###. Here the client >>>> has no way to realize that this was one and the same physical key 12. >>>> It can *not* assume that the '#' is the successor of the '3' on the >>>> same key. Because the two symbols are only on one key on US-keyboards. >>>> On a German keyboard it's '3' and '§'. And clients know nothing about >>>> the layout. >>>> >>>> So there's not a question *if* release events have to be made up, but >>>> *where*. This can be done in OSG, or in client software (given the >>>> necessary, but currently missing information: the keycode). But it looks >>>> like we already agree on that one. :-) >>>> >>>> >>>> >>>>> One also will need to decide if press 'a' and hold down then press >>>>> shift, then press release shift to do aAa should you get the events: >>>> True. The problem is that OSG events don't actually represent physical >>>> keys, but symbols. (The keycode information is thrown away, after all). So >>>> IMHO we have to think in terms of keySym sequences. And for me aaAAAaa is >>>> a-press ... a-release, A-press...A-release, a-press...a-release. The >>>> shift modifier changes symbol 'a' to 'A', and it's IMHO hard to argue >>>> that 'a' is still considered pressed during all of aaaAAA. That would >>>> mean that for the client there's 'a' and 'A' pressed at the same time >>>> for a while. That's especially bad if both keys are meant to have >>>> antagonistic effects, which is rather common, I guess. >>>> >>>> >>>> >>>>> The proper solution probably lies in have raw keyboard events, and the >>>>> modified virtual events handled in some coherent fashion exactly what >>>>> I can't say yet. >>>> Agreed. Maybe it's also time for others to add their wisdom, now that >>>> we are already a bit tired and annoyed. (Aren't we? ;-) >>>> >>>> m. >>>> _______________________________________________ >>>> osg-users mailing list >>>> osg-users@lists.openscenegraph.org >>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> _______________________________________________ >>> osg-users mailing list >>> osg-users@lists.openscenegraph.org >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
