prevent too fast typing, how to?

[Jim Ault]

trap the keystrokes, then set a global, test the new ticks...
global mm

on rawKeyDown whichKey
get the ticks - gTicksLastGoodKey
if it < gMinKeyDelay -- too short, don't pass the keystroke
else
 put the ticks into gTicksLastGoodKey
pass rawkeydown
end if
end rawkd

Jim Ault
Las Vegas



On 3/7/07 12:29 PM, "Peter Alcibiades" <palcibiades-first at yahoo.co.uk>
wrote:

> On Wednesday 07 March 2007 18:10, Jim Ault wrote:
>> Try trapping the 'rawkey down' code for the '000' and see if you can just
>> substitute the '0'
> 
> This is my problem, I can't figure how to do this.  Because I've used xev to
> find the keycodes, and what is happening is, 0 sends 90, and 000 sends 90
> three times.  Its a very rapid sequence of keypress and keyrelease, three
> times.
> 
> So I can't trap the keycode.  Sarah Reichelt had posted something a while back
> which allowed you to trap cases where the key repeats, so she set a flag and
> then caught the second sending of (eg) 0 on a key still down, without a key
> release in between.  I can't do that, because the sequence is
> keypress+keyrelease, keypress+keyrelease, keypress+keyrelease.  It seems like
> the only distinguishing thing is the speed with which it happens.
> 
> Yes, understand Andre's reservations, and I would never do it in a general
> purpose application, but in this particular case no-one is ever going to want
> to key in 000.  The pad will be used by computer-phobic older volunteers to
> key in numbers smaller than 20.  I am absolutely certain that anytime key 000
> is used, its going to be in error for the zero.  But I still feel a bit
> squeamish about putting the entry into a variable and then reformatting it to
> take out all 000s!  Something tells me, you have to make it possible to enter
> three zeros, just not using the 000 key.  Instinct!
> 
> Maybe there is no way, and we just have to deal with it in training.  It would
> be neat if we didn't have to, though.