set focus to field based on runtime error

kobiashi

Registered User.
Local time
Today, 08:29
Joined
May 11, 2018
Messages
258
hi

im trying to build some error handling into my forms, and one error code im currently trying to handle is 3314, so ive set the required perimeters in my table on each field i want as mandatory such as ALLOW ZERO LENGTH = FALSE, VALIDATION RULE =NOT NULL and VALIDATE TEXT = "required", which works great.

im using case method to handle the errors

the issue i have is there are about 12 mandatory fields in the form, my question is, can i handle all the fields from one case statements, i know i can handle it from the field such as me.fieldname.setfocus

but that would require me setting each field, before i do this, i was wondering if there was an alternative way of handling this.
 
Generally speaking you shouldn't use error handling to handle predictable events. (There are some exceptions, but you should build the form to prevent day to day use errors from occuring)

The accepted solution is to perform almost all form validation on the Forms Before_Update event. You can build a message string containing a list of missing or incorrect values, and then present that to the user when the record is attempted to be saved via the Before_Update event.

If you set a table field to requiring a value, it would be expected that you have a default value for that field, to prevent the type of error you are currently trying to trap.
 
The other method, again using the form's Before_Update (which can be canceled so that the update doesn't occur), is to highlight the fields by changing something about them. Perhaps by making the letters red (x.Forecolor = vbRed) or the background yellow (x.Backcolor = vbYellow). Or both. What you would eventually do is if someone then fills in a value, the x.LostFocus event could validate the field and reset the colors to normal.

To me it was a toss-up as to which approach was better - the message box with a long list of stuff or the color highlighting. I thought the color highlighting was more dynamic and easier for the end user to identify the hot spots.
 
+ 1 For Doc's suggestion - use the form to highlight the required and then missing values.
 
Thanks for the +1, Minty.

The UP side of this approach: Looks really great and very easy to see what is wrong.

The DOWN side: More code.

The OFFSET to the DOWN side: Most of the code looks the same and is trivially simple.
 
I do my validation one field at a time - almost always in the form's BeforeUpdate event. Therefore, I never try to accumulate errors or set colors, etc since I just put the focus in the control with the error, cancel the update and exit the sub.

This is a mindset thing and it comes from many years creating CICS transactions in the mainframe environment. The vast majority of the time, there will be no errors. In the cases where there are errors, the vast majority of the time, there will be only a single error. So, I always cater to the most optimistic situation and make error handling as simple to program as I can. If your users are regularly getting multiple errors, there is something wrong with them or the way the process is organized.
 
thanks minty, doc_man and Pat for the advice, most informative, still learning, so understanding standards is very helpful.
 

Users who are viewing this thread

Back
Top Bottom