joe_pool_is said:
There are a few things I've seen on web pages that I don't know how to do. Could someone show me how to do them?
In terms of the web all of this would be done with client-side javascript. As with many programming tasks - there are many possible solutions.
joe_pool_is said:
when entering a SSN, the form automatically jumps from one textbox to the next when the correct number of digits is entered. How does this happen?
For this one, you can bind an event to the 'onkeyup' event of the textbox (html input of type text). I'm not sure which browsers support this event but it works in IE. You could check for the length of the value - if length is all you were concerned with. In the specific example of a SSN you'd probably want to indicate to the user to use xxx-xx-xxxx format and only advance the focus when the proper format is used - or you could devise a more complex regular expression to allow a match with or without the dashes (in this example dashes must be included).
Say you had to inputs on a page, one for SSN and one for Date of Birth (DOB):
Code:
<p>SSN: <input type="text" id="txtSsn" name="txtPhone" onkeyup="testSsn();"></p>
<p>DOB: <input type="text" id="txtDob" name="txtDob"></p>
A javascript routine like this one could be used to make the focus advance to the DOB textbox once a properly formatted value was entered for the SSN:
Code:
<script language="javascript">
function testSsn()
{
var oRegExp = new RegExp(/^\d\d\d\-\d\d\-\d\d\d\d$/);
// If the ssn textbox contains text in the proper ssn format
// then set the focus to the "next" control.
if (oRegExp.test(document.all.txtSsn.value))
{
document.all.txtDob.focus();
}
}
</script>
There are a lot of differnet ways you could use 'onkeyup', 'onkeypress', 'blur' (lost focus), etc to create dynamic behavior and/or validation.
joe_pool_is said:
When entering a phone number, the form automatically inserts the parenthesis () and hyphens [i.e. (999) 999-9999],
You could use similar processing from the SSN example - perhaps reformatting the text as the phone textbox loses focus. The trick with this type of phone number formatting is that you'd have to do a lot of checking to see what the user DID enter to be able to format it the way you want it. I think this one could get a little ugly so I'm not bothering with an example.
joe_pool_is said:
2. Similar to above: Customer enters his mailing address, and below the form asks for his billing address. If Customer checks a button labeled "Mailing address is same as Billing address", the billing info is automatically populated with data from the mailing address. How does that happen?
Add an onclick event for the checkbox, see if it's checked or not, and then you just copy values from the home address to the billing address using javascript.
Your home and billing html might look like this (simple example with only address line 1):
Code:
<p>Home Address 1</p><input type="text" id="txtHomeAddress1" name="txtHomeAddress1"></p>
<p><input type="checkbox" id="chkUseHomeForBilling" name="chkUseHomeForBilling" onclick="copyHomeToBilling();"></p>
<p>Billing Address 1</p><input type="text" id="txtBillingAddress1" name="txtBillingAddress1"></p>
...and the onclick handler for the checkbox might look like:
Code:
function copyHomeToBilling()
{
document.all.txtBillingAddress1.value = document.all.txtHomeAddress1.value;
}
There are a few things to consider here. One, if the user selects the option and you copy the values do you then wipe the items if the user deselects? Or do you compare and only wipe if they're the same (because what if the user first selects this option, then changes some of the billing address, then accidentally unchecks the option - you might wipe out some valid data).
The more robust you want your app to be the more script you'll need.
Another thing to consider is - why do this at all? Ideally your database and billing logic behind the scenes is smart enough to use the home address as the billing address unless a billing address that's different from the home address was provided. When it comes time to bill you should be checking to see if there's a billing address (and that it's different from the home address) - and if not, just use the home address. This makes for less carnage in the user interface, less for the user to do, and leaves logic up to your coding.
A different approach might be to give the user the option of providing a different billing address - rather than always having them provide it in some way or making them select to use the same for both. If they decline to provide a billing address then you know to bill their home address.
joe_pool_is said:
3. If someone types in a value with an incorrect format (i.e. fields left blank or alpha letters found where numbers expected), a message box pops up to inform them. Every time I try to call a Message Box, I get an error. How do you do that?
This is called validation. Typically you do it just before the form submits. That is, you check to see if the values the user has provided are appropriate and kill the form submit if they are not, while providing some feedback to the user. There are many ways to approach this. If you're using ASP.Net you can add asp validation controls to your webform and an asp validation summary which can take care of a lot of this stuff for you.
Otherwise, in raw HTML or ASP you might add an 'onsubmit' handler to your form at:
Code:
<form method="post" action="whatever.asp" onsubmit="return validateForm();">
The 'return' part of the event above is important - because if validation fails a return of 'false' needs to happen to stop the form post from happening.
A simple validation routine might look like this:
Code:
function validateForm()
{
var sValidationMessage = "";
var bIsValid = true;
// Setup reg exp for testing the SSN.
var oSsnRegExp = new RegExp(/^\d\d\d\-\d\d\-\d\d\d\d$/);
// See if SSN is filled in - and if it is if it's in a valid format.
if (document.all.txtSsn.value.length == 0)
{
sValidationMessage += "SSN is required\n";
bIsValid = false;
}
else if (!oSsnRegExp.test(document.all.txtSsn.value))
{
sValidationMessage += "Invalid SSN\n";
bIsValid = false;
}
// See if DOB is filled in.
if (document.all.txtDob.value.length == 0)
{
sValidationMessage += "DOB is required\n";
bIsValid = false;
}
// Show message if anything was invalid.
if (sValidationMessage.length > 0)
{
sValidationMessage = "The form could not be sumitted due to the following errors:\n\n" + sValidationMessage;
alert(sValidationMessage);
}
return bIsValid;
}
The code above might work on the previously mentioned ssn and dob textboxes. You have to build conditionals depending on what kind of input you want. In the example above the routine checks to see if dob and ssn have been entered - and it also checks for format of the ssn. A string variable is built up containing all of the validation error messages. If any validation failures are discovered an alert is used to show the user and the routine returns 'false', which will kill the form submit. In response to the first question I showed a little 'testSsn' function - that function could be modified to return true or false depending on the validity of the SSN format - and you could then use that function in both places (for the focus advancing - and you'd just ignore the return value, and in the validation routine, rather than repeating the regexp setup).
Form validation can get to be quite complex if you have a lot of data with a lot of specific formats. You can generally use regular expression objects to check for email, phone, ssn, and other types of numerical formats. A lot of times you also need multiple validation checks for a given textbox - for ex you may need to check that the textbox is filled in (for a required field) and check for a valid format if it is filled in.
.Net provides a bunch of validators (required field, range, reg exp, custom) that make doing client-side validation a lot less painful, a lot more user-friendly and dynamic (like showing red asterisks next to offending fields), and with the validation summary allows you to provide overall validation feedback very easily.
-----
Anyways, you've asked a lot of questions that can have a lot of different answers. Hopefully all my rambling has given you some indication of how these topics can be approached. Each of your questions is a fairly robust topic. You might find more extensive examples searching google. You might also see what you can come up with yourself in the context of your own project then post specific questions if you encounter problems.
Good luck,
Paul