Retaining focus after postback
-
I'm tasked with helping a developer finish up a web page that collects information about an order and populates some SQL Server tables. ASPX with C#. I'm not a C# guy, but my main job here is to keep him on task, interface with the dept. that will need this, and validate the data design. At present, there are some issues with postbacks. He does a good bit of validation, mostly to ensure fields aren't blank, and posts back upon exit of a good many fields. One problem is retaining focus after postback. The user enters a value, presses tab, and a postback occurs. Instead of the focus moving to the next field, there seems to be no field with focus after the postback, which forces the user to click in the next field with the mouse. So instead of being able to tab to fields as expected, the user keeps having to use the mouse to get the focus to the appropriate field. This is not very desireable at all. Another issue is what fields cause a postback. An example would be a field that can be empty (zero), but if it's >0 another field needs to be populated. The postback occurs after the first field and an error message is displayed next to the second field saying it can't be empty, yet the user hasn't even had a chance to enter anything in that field. This is most likely a simple fix of where the validation originates from (the second field instead of the first), but the programmer seems to think this is hard to do or not doable. I may have to dig into C#, but some help here would be appreciated. Thanks, Russell
-
I'm tasked with helping a developer finish up a web page that collects information about an order and populates some SQL Server tables. ASPX with C#. I'm not a C# guy, but my main job here is to keep him on task, interface with the dept. that will need this, and validate the data design. At present, there are some issues with postbacks. He does a good bit of validation, mostly to ensure fields aren't blank, and posts back upon exit of a good many fields. One problem is retaining focus after postback. The user enters a value, presses tab, and a postback occurs. Instead of the focus moving to the next field, there seems to be no field with focus after the postback, which forces the user to click in the next field with the mouse. So instead of being able to tab to fields as expected, the user keeps having to use the mouse to get the focus to the appropriate field. This is not very desireable at all. Another issue is what fields cause a postback. An example would be a field that can be empty (zero), but if it's >0 another field needs to be populated. The postback occurs after the first field and an error message is displayed next to the second field saying it can't be empty, yet the user hasn't even had a chance to enter anything in that field. This is most likely a simple fix of where the validation originates from (the second field instead of the first), but the programmer seems to think this is hard to do or not doable. I may have to dig into C#, but some help here would be appreciated. Thanks, Russell
Why are you validating on the server when the user tabs out? I'd keep the "light" validation on the client side with JavaScript and save the postbacks for submitting the form. Then you can set the focus to the field that has errors, or move them on. That validation you are mentioning should definitely be clientside. Is the developer rolling their own code, or using something supplied by the framework like a RequiredFieldValidator that can be set to dynamic and will run on the clientside without a postback? If there is some compelling reason why you would roundtrip every time a user leaves a field (which seems to make sense only for a small internal app without many concurrent users, otherwise it won't scale well) then I'd look at using a callback instead of a postback for the validation. They are not complicated to wire in and infinitely improve the user experience while cutting down on the size of network traffic (have you used Fiddler or something similar to see how much data, like ViewState, gets thrown around when you postback?)
Jeremy Likness Latest Article: Whats in Your Collection? Part 1 of 3: Interfaces Blog: C#er : IMage
-
Why are you validating on the server when the user tabs out? I'd keep the "light" validation on the client side with JavaScript and save the postbacks for submitting the form. Then you can set the focus to the field that has errors, or move them on. That validation you are mentioning should definitely be clientside. Is the developer rolling their own code, or using something supplied by the framework like a RequiredFieldValidator that can be set to dynamic and will run on the clientside without a postback? If there is some compelling reason why you would roundtrip every time a user leaves a field (which seems to make sense only for a small internal app without many concurrent users, otherwise it won't scale well) then I'd look at using a callback instead of a postback for the validation. They are not complicated to wire in and infinitely improve the user experience while cutting down on the size of network traffic (have you used Fiddler or something similar to see how much data, like ViewState, gets thrown around when you postback?)
Jeremy Likness Latest Article: Whats in Your Collection? Part 1 of 3: Interfaces Blog: C#er : IMage
I have been thinking clientside validation is the way to go, also. I'm coming in late to this project and we have a deadline looming on 9/1, so that's a consideration when making changes. I only realized we had this problem yesterday, unfortunately. The page is for external users, but the volume will be low (about 1600 users entering one order each over the period of two - three months). As you can see, the amount of traffic is not really an issue, but serverside validation may not be the way to go due to these other issues. Thanks for your reply.
-
Why are you validating on the server when the user tabs out? I'd keep the "light" validation on the client side with JavaScript and save the postbacks for submitting the form. Then you can set the focus to the field that has errors, or move them on. That validation you are mentioning should definitely be clientside. Is the developer rolling their own code, or using something supplied by the framework like a RequiredFieldValidator that can be set to dynamic and will run on the clientside without a postback? If there is some compelling reason why you would roundtrip every time a user leaves a field (which seems to make sense only for a small internal app without many concurrent users, otherwise it won't scale well) then I'd look at using a callback instead of a postback for the validation. They are not complicated to wire in and infinitely improve the user experience while cutting down on the size of network traffic (have you used Fiddler or something similar to see how much data, like ViewState, gets thrown around when you postback?)
Jeremy Likness Latest Article: Whats in Your Collection? Part 1 of 3: Interfaces Blog: C#er : IMage
Checking for blank fields, etc should definetly be done on the client side. Here is an example Javascript validation routine:
function valToFormulator() {
// alert(document.getElementById('<%=tbxCustomerID.ClientID%>').value);if ((document.getElementById('<%=tbxCustomerID.ClientID%>').value == "") ||
(document.getElementById('<%=tbxContactID.ClientID%>').value == "")) {
alert("You must select a contact before sending to the flavor chemist.");
return false;
}
else
return true;
}On the ASP.NET button, I have the following attribute:
OnClientClick="return valToFormulator();"If the validation routine returns a "false", then the PostBack does not occur and the validation routine displays the Popup alert box with the error message. Have your programmer try it out on a simple field validation where a field cannot be blank. You will be much happier with the performance. :thumbsup: