Angus Leeming <[EMAIL PROTECTED]> writes:
| On Tuesday 10 December 2002 2:19 pm, Lars Gullik Bjønnes wrote:
>> Angus Leeming <[EMAIL PROTECTED]> writes:
>> | Lars, the attached patch to xforms' forms.c cures these two bugs in
>> | xforms handling of key events.
>> |
>> | o xforms should swallow null keyevents. They occur during composition of
>> | multi-byte chars. The problem was reported and a solution proposed here:
>> |
>> | o xforms should pass FL_KEYRELEASE events to the widgets. Currently they
>> | are swallowed.
>> |
>> | I find that holding down the 'a' key continuously results in this
>> | lyx -dbg 524292 (workarea + key) output.
>> | Ie each and every KEYPRESS event is followed by a KEYRELEASE event.
>>
>> Look at the time difference between the KEYRELEASE and KEYPRESS
>> events.
>
| Why? Ie, I don't understand what you're attempting to do with this code.
Just do it....
KeyRelease event, serial 27, synthetic NO, window 0x4a00001,
root 0x3a, subw 0x4a00002, time 148348763, (52,23), root:(721,1037),
state 0x0, keycode 40 (keysym 0x64, d), same_screen YES,
XLookupString gives 1 characters: "d"
KeyPress event, serial 27, synthetic NO, window 0x4a00001,
root 0x3a, subw 0x4a00002, time 148348763, (52,23), root:(721,1037),
state 0x0, keycode 40 (keysym 0x64, d), same_screen YES,
XLookupString gives 1 characters: "d"
What we do not want is cursors, auto-repeat chars that just continue
to go after the key has been released. so we use xsync for this.
The problem is to know when to run this xsync, we want to loose as few
xevents as possible.
--
Lgb
