Please bear with this new Xojo user. I’m trying to code a Web number field to allow only numbers from 1 to 53 (it’s a Week Number field). I’m used to working with Filemaker, where, if the user enters an incorrect value, I can have a script blank the field and eat the user’s keystroke that takes them out of the field. Here’s what I put in for its Lost Focus event handler:
If (Val(Me.Text) > 53) or (Val(Me.Text) < 1) Then
MsgBox "Week must be a number from 1 to 53."
Me.Text = ""
WeekNumber_Field.SetFocus
Return
End If
I want the user to be placed back in that field after the code blanks it (if they enter an incorrect value). Let’s say the user enters 54 in that field. The above works when the user mouses out of the the field. With respect to tabbing out of the field, it works only if tabbing out of the field places them in another field. If tabbing out of the field results in no field having focus, the field is blanked but they are not returned to it.
Personal observation… I find it annoying to be checked as I type… (ie. Keydown)… 1) people make typos that they catch just as fast as the computer (sometimes), and 2) Beep… uh … ok what was that beep and what does it mean?
MY personal preference (depending on the screen) is to allow the user to enter everything… and fact check it just before committing it… and then light up the offending entries, so there is no mistake as to what is wrong… in some cases I even pop up an explanation.
I have seen many buggy apps that didnt save a changed value due to this: the window can close without the control losing focus, for example.
Dave’s approach is my preferred coding style and as a user too.
(But: pet hate - Sometimes I click OK and get a message to say one field was bad, only to find ALL THE FIELDS EMPTIED.
If I ever meet the coder who did that, I will not be answerable for my actions… ;> )
Imagine your window wants to know gender, title, and surname
When you click save, you find that someone has entered Male and Mrs.
These two are valid options for the fields, but not in combination, so you report a problem with one of them and put the focus into that field.
For a number that needs to be between (say) 32 and 212 (fahrenheight degrees of liquid water) , if the user enters 22, then you say ‘too cold’ and put the focus into that field.
But if the number is between 32 and 212, you allow it to save.
Obviously if you prevent save in this way, you must also have the ability to CANCEL the screen and not save, otherwise the user is locked into entering any old value just to keep the screen happy.
So while waiting for that Save button to be pushed. if there were say 20 cells that required input and 19 of them were not the expected data then the user will have to wait until he/she clicks save to be guided with the message box indicating that list of 19 items.
Using the lost focus for each data input and doing a final check on the save seems more logical to me.
[quote=245763:@Jeff Tullin](But: pet hate - Sometimes I click OK and get a message to say one field was bad, only to find ALL THE FIELDS EMPTIED.
If I ever meet the coder who did that, I will not be answerable for my actions… ;> )[/quote]
[quote=245767:@Lennox Jacob]So while waiting for that Save button to be pushed. if there were say 20 cells that required input and 19 of them were not the expected data then the user will have to wait until he/she clicks save to be guided with the message box indicating that list of 19 items.
Using the lost focus for each data input and doing a final check on the save seems more logical to me.[/quote]
You should do both. Check individual values as early as practical without getting in the way. Then do a final check for valid combinations of values before saving.