Error Handling (1 Viewer)

[tmyers]

In the process of working on my application today, a thought occurred to me as I was testing things.
While testing I get the "You must enter a value in *table* field" a lot. Mostly due to the incomplete nature of the application. Things are still being built after all, so it's to be expected.

However, I have certain entry forms that even though they are mostly complete, could still cause that error due to a user possibly getting ahead of themselves with entering data, or maybe pressed tab one too many times and didn't notice. Certain fields on my forms REQUIRE data entered in other controls first (I have tried to layout my forms and tab numbers so it makes the users "flow" in the direction I want).

On a post I made earlier today (I was working on a form with list boxes, combo boxes etc), a user would have to pick a field in the list box, then pick a value in the combo then enter another value in a text box. Things essentially HAVE to go in that order. However, what if the user forgets to pick an item in the list box first and tries to interact with the combo? It throws that "must enter value" error (and the only method I have used to "fix" it is to completely close the form), but that is horrible practice for an end user.

So my questions is this, can you do a Before Update event that invokes OnError to help remedy that? Say if the user accidently breaks the order they are supposed to go it, before they cause that error and get stuck a message box pops up and says hey, you need to do this over here first. I'm sure I could probably come up with a VBA error handler, but the macro builder has the OnError, so I assume Access has built in features to deal with this.

 

[theDBguy]

Hi. Actually data entry validation is best done in the BeforeUpdate event. You can do a search on using Tags in the BeforeUpdate event to validate a Form.

 

[Isaac]

couple of my thoughts

or maybe pressed tab one too many times and didn't notice

IF by this you meant the form actually cycling to a new/another record, this is why I typically disable all of the counter-intuitive ways that Access tries to automatically save things and move around without people expecting it would, (there is nothing worse than an end user hitting pagedown or tab and getting a validation error record-level, and thinking "What the heck? I wasn't even intending to finish this record yet, nor go anywhere else)......so, provide explicit buttons (or clickable Something's) to do so...utilizing Ctrl+Letter if appropriate, for keyboarders who might otherwise perceive a loss in efficiency. Doing it the way I'm recommending ultimately will greatly reduce the variety of events you have to hook into wondering "Hmm, this event might fire here, better trap for x".....collapsing all that to explicit commands results in much easier & cleaner development. If you didn't mean this never mind.

One technique I use sometimes to, again, avoid having to hook into all kinds of error events and possibilities, is to Disable controls until such time as they are contextually appropriate/available...then immediately Enable them. A great example is a listbox with nothing selected, I disable the button associated with it until the listbox selected items count is >0. Making them invisible/visible is an option too, but I think Disabling-Enabling provides the best balance of visually explanatory cues for the end user.

One way or another, making functionality not available until the correct timing -- and creating a visual experience that cues the user into exactly what is expected next, or has been accepted, will save you having to write tiny bits of code in 100 other places, and save THEM from having no idea if what they are doing is acceptable until the end. I see it all the time. Just a thought.

PS..I agree with dbGuy that generally speaking a form's BeforeUpdate event is a good place to put most or all validation, but in some cases it users may resent taking the trouble to fill out a form with many details and not be told what is wrong until the final click. (If I am on a website, for example, I'd rather them tell me my registered username is taken, or I've used that password before, prior to the final click). IMHO.

 

[tmyers]

I like the idea of hiding the controls until something is selected. That (to me) gives a nice visual indication of what they are supposed to do next (some of the people who are going to use this application are not the most tech savvy people).

While tinkering around and reading, I did come to the same conclusion that error handling is always best handling on the Before Update event. I was actually just reading another thread on here (granted it was like 15 years old) about it.

 

[tmyers]

Out of pure curiosity, could you actually use the macro builders OnError to handle it though? Or would it require VBA?