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
