Re: onKeyPress()
Derek, you mentioned
According to the Win32Lib documentation for onKeyPress(), and I quote, ...
"
If you want Windows to ignore the key, set the return value to -1.
This is not in my documentation which I thought was current. Have I got the
wrong doc? I'm finding I need a lot more info than I currently have so I
don't have to ask so many question.
..george
----- Original Message -----
From: "Derek Parnell" <ddparnell at bigpond.com>
To: "EUforum" <EUforum at topica.com>
Sent: Monday, August 06, 2001 5:19 PM
Subject: Re: onKeyPress()
>
>
> ----- Original Message -----
> From: "George Walters" <gwalters at sc.rr.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Tuesday, August 07, 2001 1:20 AM
> 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.
>
>
>
>
>
|
Not Categorized, Please Help
|
|
