Re: onKeyPress()

new topic     » goto parent     » topic index » view thread      » older message » newer message

----- Original Message -----
From: "George Walters" <gwalters at sc.rr.com>
To: "EUforum" <EUforum at topica.com>
Subject: onKeyPress()


>
> I've had to leave for a couple of days (mandatory appearance at a
> mother-in-law weekend event)...but I took my computer so all was not a
loss.
> I've run into several items
>
> 1. I'm trapping all keystrokes now to handle but when the 'esc' or
'return'
> key is pressed, i receive the keystroke but windows 'beeps'. Why is this
and
> how to get rid of it? (on my office computer it 'clicks a sound' and on my
> win2000me laptop i get a loud 'bell')

According to the Win32Lib documentation for onKeyPress(), and I quote, ...
"
 If you want Windows to ignore the key, set the return value to -1.


 if find(keyCode,"0123456789") then
    returnValue(-1) -- ignore digits.
 end if
"

When you don't do this, Windows also uses the key that was pressed but if
the control that has focus can't use the key, it beeps/bells/clicks ..
whatever. However, there is also a mistake in v0.55x of the library in that
some Alt-Key combinations used to "press" buttons also beep because the
corresponding key-up event is not thrown away.


> 2. Are there any windows editText data types like date, numeric etc where
> windows will edit or use a print mask to display what is typed. (i.e. I
> would like to type in for a date 80601 and have displayed 8/06/01, for $
> amounts to always display 5.5 as 5.50)

>From memory, Windows API doesn't have any edit mask capabilities built in.
This means that you will have to do this yourself. You will need to decide
the best way to do this. The choices are generally ...

a) Trap every keystroke and only allow those that match the datatype and
format you want. To do this, you need to keep some context info in between
keystrokes to "know" where you are up to. You must take into consideration
things like backspace, delete, arrow keys etc....

b) Wait til the user has completed the field and examine what they entered
on the onLostFocus() event. If they put in something wrong you need to
either regain focus or make a note somewhere on screen so the user knows to
go back and fix it.

c) Ensure that the user cannot enter bad data in the first place. This is
only effective for "bounded data". That is, where the data has some bounds
that can be enforced. For dates, this usually means displaying a calendar
for them to choose a date rather than key in any old thing. For data that
has specific ranges, use a slider or spinner. For data that has a limited
number of possible choices (eg Days of the week), use a list or combo.


> 3. If I am in data entry mode on the screen and change to another windows
> task and then return to the screen, windows starts the data entry at the
> beginning of the fields, not where I left off. Why is this and do I have
to
> know I was switched out and set the focus when I return?

This is a mistake in Win32lib. I really must get around to fixing this one.
I've done some research and haven't yet tracked down why focus is
transferring back to the first item when the window regains focus.

-----
cheers
Derek Parnell.

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu