E-mail form field verification question

W

Webspert

Is there a utility to use in FP2002 that will force an e-mail address in a
front page form field to be formated correctly? That is, to make sure it
has (e-mail address removed)? Then, is there another one that will
compare two form fields to make sure they are identical?

Put simply, when a potential customer enters an e-mail address in a field, I
want to make sure it is at least formated correctly. Then, in the
"re-enter e-mail address" form field, I want to make sure the two addresses
are the same or the form won't be submitted.

Any ideas?
 
J

Jim Buyens

-----Original Message-----
Is there a utility to use in FP2002 that will force an
e-mail address in a front page form field to be formated
correctly?
No.

That is, to make sure it has (e-mail address removed)?

I understand, but no.
Then, is there another one that will compare two form
fields to make sure they are identical?
No.

Put simply, when a potential customer enters an e-mail
address in a field, I want to make sure it is at least
formated correctly. Then, in the "re-enter e-mail
address" form field, I want to make sure the two
addresses are the same or the form won't be submitted.

Any ideas?

Actually, yes.

1. In HTML view, add the following attribute to the text
box for the E-Mail address:
onblur="valEmail(this);"
2. Add the following script to the <head> section of
your page:
<script>
function valEmail(txtBox) {
if (txtBox.value == ""){
return 0;
}
re = /^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,})+$/;
if (re.test(txtBox.value) == false) {
alert("E-Mail Address '" + txtBox.value +
"' is invalid.");
txtBox.focus();
txtBox.select();
}
}
</script>
3. Switch to Design view.
4. Right-click the text box and then choose Form Field
Properties.
5. Click the Validate button.
6. Set Data Type to Text and then, under Data Length,
select Required.
7. Click OK and OK.

FYI, the onblur event occurs whenever the text box loses
focus (such as when the visitor tabs to or clicks another
form field). When that event occurs, the valEmail
function allows the field to be blank, but otherwise
matches its value to a so-called "regular expression"
pattern. If the pattern matches, fine. Otherwise, the
function displays a message box and returns focus to the
text box.

The reason for allowing a blank entry is that the visitor
may decide not to fill out the form, and to click some
other hyperlink instead. A blank entry provides a means
of escape.

In any case, the FrontPage validation rule prevents
actually submitting the form without a blank e-mail
address. This is a rule you need to have anyway, in case
the visitor never tabs to the e-mail text box.

Custom validation scripts and FrontPage validation
generally have a hard time coexisting. This approach
seems to be OK, though, because the custom validation
occurs when the form field loses focus, and the FrontPage
validation occurs when the visitor submits the form.

Jim Buyens
Microsoft FrontPage MVP
http://www.interlacken.com
Author of:
*----------------------------------------------------
|\---------------------------------------------------
|| Microsoft Office FrontPage 2003 Inside Out
||---------------------------------------------------
|| Web Database Development Step by Step .NET Edition
|| Microsoft FrontPage Version 2002 Inside Out
|| Faster Smarter Beginning Programming
|| (All from Microsoft Press)
|/---------------------------------------------------
*----------------------------------------------------
 
W

Webseprt

Thanks very much, Jim. It worked perfectly for the e-mail form field. My client wanted the form to have an e-mail: text box then another for re-enter e-mail. Then they got a form back that had the address slighlty different in each - i.e., (e-mail address removed) in the first one, then (e-mail address removed) in the second, and wasn't sure which was the correct one. If there's nothing to be done to compare the two and force the customer to think about it and enter the accurate one twice, we might just as well go to only entering it once

Thanks again for the help.
 
J

Jim Buyens

Webseprt said:
Thanks very much, Jim. It worked perfectly for the e-mail form field.
My client wanted the form to have an e-mail: text box then another for
re-enter e-mail. Then they got a form back that had the address slighlty
different in each - i.e., (e-mail address removed) in the first one, then
(e-mail address removed) in the second, and wasn't sure which was the correct
one. If there's nothing to be done to compare the two and force the customer
to think about it and enter the accurate one twice, we might just as well
go to only entering it once.

Oh, I thought the e-mail syntax checking was your first choice, and
that the comparison of double entries was a fall-back.

The best way of comparing two fields is to capture the form's onSubmit
event, and perform the check at that time. But FrontPage form field
validation also needs to capture the onSubmit event, and this creates
a conflict. You can only have one onSubmit event handler.

Sometimes, you can change the Submit button to an ordinary pushbutton
with an event handler, as in:

<input type="button" value="Submit" name="btnSub" on
click="customVals();">

The event handler checks the condition and calls the form's submit()
method only if everything seems OK. Here are three tags and a script
that illustrate this:

<input type="text" name="txtEmailA" size="20">
<input type="text" name="txtEmailB" size="20">
<input type="button" value="Submit" name="btnSub"
onclick="customVals();">

<script>
function customVals(){
if (document.forms[0].txtEmailA.value ==
document.forms[0].txtEmailB.value){
document.forms[0].submit();
}else{
alert("E-Mail Addresses don't match.");
}
}
</script>

This still appears to skip browser-side form field validation, but if
the Web server is running the FrontPage Server Extensions, FrontPage
will perform the FrontPage checks on the server.

The disadvantage is that the visitor gets a new separate error page
with an error message and instructions to click the Back button. This
can be confusing, because it's a different procedure than responding
to the alert boxes that custom validation scripts display.

Jim Buyens
Microsoft FrontPage MVP
http://www.interlacken.com
Author of:
*----------------------------------------------------
|\---------------------------------------------------
|| Microsoft Office FrontPage 2003 Inside Out
||---------------------------------------------------
|| Web Database Development Step by Step .NET Edition
|| Microsoft FrontPage Version 2002 Inside Out
|| Faster Smarter Beginning Programming
|| (All from Microsoft Press)
|/---------------------------------------------------
*----------------------------------------------------
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top