Forums

by Dave Mellow >> Thu, 17 Nov 2005 21:50:55 GMT

In terms of enhancements, maybe not a biggie but something I often think about when coding... there's what I think's a nice feature in a certain other language.

OK, the scenario is to do with input validation on forms, and has to do with this type of situation (this is a bit simplistic, but illustrates my point)

We have this code...

txtBox1_click(textbox: TextBox input) updating;

vars
begin

if textbox.text.trimBlanks = "" then
// probably inform user, beep or whatever here
textbox.setFocus;
endif;
end;

And of course the problem is, what say the user clicked a button that is say "Undo" or "Cancel" where we don't want that validation to occur and in fact they are now locked into the textbox. OK, obviously we would use some more sophisticated methodology, but in my experience it tends to get messy and now to my suggestion that I think is a nice way of handling this type of situation...

- Controls have a "causesValidation" property which is by default set to "true"
- They also have a "validate" method which would be used instead of the "lostFocus" method, e.g.

txtBox1_validate(cancel : Boolean output)
varsbegin

if txtBox1.text.trimBlanks = "" then
// inform the user or whateever)
cancel := true; // this causes focus to be returned to this textbox.
else
cancel := false;
endif;
end;

Now, this validate method is only invoked when another control with the "causesValdation" property set to "true" gains focus (remembering all controls by default are populated with this value), so during form design we change that property to "false" for our "Undo" button.

Yes, I do understand there are lots of ways to handle this, but I always liked this particular feature. Also, yes, in general I prefer doing all validation upon final update of form but sometimes there are needs to handle it during a users input.

Curious any thoughts about this?

Regards
Dave Mellow

by Dave Mellow >> Thu, 17 Nov 2005 22:10:55 GMT

Sorry, first example should have been for "lostFocus" event, not "click". Doesn't make much sense otherwise! So...


In terms of enhancements, maybe not a biggie but something I often think about when coding... there's what I think's a nice feature in a certain other language.

OK, the scenario is to do with input validation on forms, and has to do with this type of situation (this is a bit simplistic, but illustrates my point)

We have this code...

txtBox1_lostFocus(textbox: TextBox input) updating;

varsbegin


if textbox.text.trimBlanks = "" then
// probably inform user, beep or whatever here
textbox.setFocus;
endif;
end;

And of course the problem is, what say the user clicked a button that is say "Undo" or "Cancel" where we don't want that validation to occur and in fact they are now locked into the textbox. OK, obviously we would use some more sophisticated methodology, but in my experience it tends to get messy and now to my suggestion that I think is a nice way of handling this type of situation...

- Controls have a "causesValidation" property which is by default set to "true"
- They also have a "validate" method which would be used instead of the "lostFocus" method, e.g.

txtBox1_validate(cancel : Boolean output)
varsbegin

if txtBox1.text.trimBlanks = "" then
// inform the user or whateever)
cancel := true; // this causes focus to be returned to this textbox.
else
cancel := false;
endif;
end;

Now, this validate method is only invoked when another control with the "causesValdation" property set to "true" gains focus (remembering all controls by default are populated with this value), so during form design we change that property to "false" for our "Undo" button.

Yes, I do understand there are lots of ways to handle this, but I always liked this particular feature. Also, yes, in general I prefer doing all validation upon final update of form but sometimes there are needs to handle

it during a users input.

Curious any thoughts about this?

Regards
Dave Mellow

by Patwos >> Sun, 20 Nov 2005 4:31:24 GMT

Personally I have always found it frustrating to have a system tell me I must enter data into a particular field and forcing focus back to that field.

For example, it may be that you want to open or swap to another form in the application to refer to some prior information to help with completing the form in question. Unfortunately if the person who coded the system has a lostFocus that forces you to enter something into a required field, this then gets in your way and can become particularly frustrating from a useability perspective.

For this reason, I now do not validate on lostFocus in a manner that will display a msgbox or force focus back on the user. I also avoid coding lostFocus events as much as possible to reduce traffic to the AppServer in a thin client environment and therefore ensure maximum responsiveness to the user performing the data entry, particularly on a slower network connection to the AppServer. I have found that most data entry users prefer an application to be as responsive as possible and they particularly hate situations where the focus is being forced back to a particular control other than when missing/required data is detected during save processing and especially if a msgbox is also displayed as this again interrupts their data entry processing.

Similarly I try to avoid the use of modal dialogs as much as possible so that the users are free to refer to other data in the application in the middle of whatever process they may currently be working on. Obviously there are times where for reasons of data integrity it is somewhat easier for the programmer to use modal dialogs, however in the long run the users will be much happier with their application if we do spend the time doing the "harder" work underneath the hood to avoid using modal dialogs and still maintain our data integrity.

The same principal applies with allowing the user to do an "intermediate" save without having yet selected all the required combobox values or filled in the required fields. Yes, it's a lot harder for us to code a system that allows the user to save an incomplete "whatsit" with lots of required fields currently incomplete, but if we write systems that allow the user to save as/when they want and code the system to handle incomplete "whatsits" it gives the user a much better experience with our application. Unfortunately we're not working in a perfect world so of course time and budgetry constraints often prevent us from taking this approach but wherever possible it's nice to keep these ideas to the forefront and use them when we can.

I guess I'm somewhat over my $0.02 here so I'll step down and let someone else have my soapbox.

Pat.