Email Invalidity Tester [Beta-8 Advanced]

[Kent Searight]

Solution / : Email Invalidity Tester

Description: Checks for invalidities in email address syntax and displays results in a calc field and an auto-enter calc field. The use of 2 different fields to display results is to provide the user with:

a.) A warning that a syntax error has occurred (red text)

b.) An explanation of the error in a Tooltip that helps the user fix the problem.

Overview:

If any of the syntax tests in the calculation fail, the result is an explanation of the syntax failure and is displayed in a Tooltip when you hold the mouse pointer/cursor over the email field. Tooltip doesn’t display if text in email field is not red.

The email field itself is an auto-enter calc that strips out spaces and tests if the calculation is empty. If empty, the email field displays its value in the text color and text style set at the field level. If not empty it displays the value in red and the text in plain style.

The top-level domain (the suffix, i.e. .com, .net, .edu, etc.) is checked against a list of approved suffixes. The list is stored in a single global field in this file. For best results, the list should be updated routinely.

An up-to-date list can be found at http://data.iana.org/TLD/tlds-alpha-by-domain.txt

Working Under: 8 Advanced

Solution Status: Beta

Pre-requisites: The most up-to-date list of IANA approved domain suffixes

Author(s): Kent_S

Date: 05/08/06

Credits: Kent Searight

Instructions / Other Info: The whole idea behind this is to alert the user that the email address they entered has a syntax error and then show the user the reason for the error. I tried to do all this in the email field alone and found that I didn't like any of the solutions from the user's perspective. That's when I decided to incorporate a calculation field into the solution that would be used to show what the error is and also to serve as the trigger for the auto-enter calc email field.

If you try this example file and find that I've missed some syntax errors that should be tested for, I'd appreciate your feedback. Actually, I welcome any comments about it...good, bad or otherwise.

Cheers!

Disclaimer:

FM Forums does not endorse or warrantee these files are fit for any particular purpose. Do not post or distribute files without written approval from the copyright owner. All files are deemed public domain unless otherwise indictated. Please backup every file that you intend to modify.

Email_Invalidity_Tester.fp7.zip

[Genx]

Wouldn't this be better achieved with a custom function calc vs a script that has to be executed? Still i suppose it depends on what you want to happen.

There's one on brian dunning site somewhere in case anyone wants a custom function.

~Genx

[Kent Searight]

Last time I looked there wasn't a script in the sample file. It is done with 2 calculations, just as I stated in the first line of the description.

My reasons for not posting this in the Custom Functions part of the Forums are:

Those without FM 8 Advanced (who might otherwise ignore the CF section of the Forums) will still download and view the calculation, and ...

The sample file is intended to be a more complete solution from the perspective of User Interface, hence the calculation field and the auto-enter calc field that work in conjunction with each other to alert the user of a problem and then to describe the problem.

BTW In "real life" the calculation is used in my solutions as a custom function, although there's nothing that says that that has to be the case.

[Genx]

Sorry, I so didn't finish reading it. I just figured if it was a solution it would involve a script or something. My bad, I'll actuailly check it out this time, the tooltip sounds like a good idea.

Cheers,

~Genx

[LaRetta]

Hey Kent! Wonderful!

I've been meaning to add email validation in the current solution but haven't gotten around to it. You not only saved me time but you did a better job than I would have. And it will be easy to slide right into my solution. Thank you! The tooltip idea is great and I'm going to use that on my phone number (and website) fields as well.

LaRetta

[Kent Searight]

Hi LaRetta,

Glad you like it. Tooltips rock when it comes to enhancing the user experience.

I look forward to hearing if it stands the tests of everyday use with your users. And please let me know if you think there's any way I can improve on it.

Keep in mind, as I'm sure you've already realized, that this isn't a true validation solution. Someone could still enter an address with correct syntax but that doesn't mean the address actually exists. To validate the actual existence of the address would require querying the domain server for that address.

Enjoy!

[LaRetta]

I had to laugh at myself ... with phone numbers awhile back, I set the field to Auto-Enter (Replace) and the calculation default result (if it failed) changed the field to "ERROR." I implemented it and updated the fields and ... oooops ... Thank God for backups.

I like the way you've combined the Auto-Enter (Replace) with the calculation because it provides proper feedback by changing color yet the REASON is displayed in the tooltip (and they can see both simultaneously). Attempting to incorporate the error message within the Auto-Enter (Replace) is NOT a good idea. With this setup, Users can 1) know when a field is incorrect, 2) make corrections to the existing data and 3) know exactly what to change. :wink2:

[Genx]

I was a bit doubtful before seeing the file but... awesome idea re the tooltips. I've had the phone validation for some time. I would have my users specify a number type and validate the format accross that with the number turning red if incorrectly formatted. While this was useful, users sometimes questioned the reason as to why a number was shown as incorrectly entered and a tooltip would be an excellent way to give them the reason for the error.

This truely is a whole new way of dynamically interacting with the user. Oooh, the idea has me excited :

Cheers Kent,

~Genx

[Kent Searight]

Attempting to incorporate the error message within the Auto-Enter (Replace) is NOT a good idea.

I agree.

Another approach I tried before was to color the text in error in the field itself, but that doesn't work well either when:

a.) Something is missing...it's difficult to color nothing!

b.) The error is a comma...very difficult to discern something as small as a [color:red],