473,388 Members | 897 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,388 software developers and data experts.

Parsing phone numbers

I'm curious if there are others who have a better method of
accepting/parsing phone numbers. I've used a couple of different techniques
that are functional but I can't really say that I'm totally happy with
either.

1. My first technique was to restrict the users to entries that could only
be 3 character, 3 characters, 4 character (area code, prefix, suffix,
respectively). I would null out any inputs that were non-numeric (except the
backspace). This worked reasonably well, except it was somewhat ugly to look
at.

2. My second technique was to give the user a single text entry box and
auto-format the string with hyphens as they entered the phone number. I then
parse the phone number, knowing exactly where the hypens are located.

What I'm looking for is some better ideas. Anyone?
Nov 22 '05 #1
4 5218
> What I'm looking for is some better ideas. Anyone?
Yes. Trust the user and accept more.
Why:
- numbers having extensions
- numbers with letters: 1-800-COLLECT
- numbers outside U.S.

I always get annoyed when I can't imput my data on some web sites
and quite a few of them lost me as a buyer.
Same with registration forms.

--
Mihai
-------------------------
Replace _year_ with _ to get the real email
Nov 22 '05 #2
On Sun, 23 May 2004 01:56:52 -0500, "Earl" <brikshoe<at>comcast<.>net>
wrote:
I'm curious if there are others who have a better method of
accepting/parsing phone numbers. I've used a couple of different techniques
that are functional but I can't really say that I'm totally happy with
either.

1. My first technique was to restrict the users to entries that could only
be 3 character, 3 characters, 4 character (area code, prefix, suffix,
respectively). I would null out any inputs that were non-numeric (except the
backspace). This worked reasonably well, except it was somewhat ugly to look
at.

2. My second technique was to give the user a single text entry box and
auto-format the string with hyphens as they entered the phone number. I then
parse the phone number, knowing exactly where the hypens are located.


My personal preference is to let the user type what they want. Give
them a free entry text box. Then, in validation code (client or server
depending on your whims) you parse out what I typed and deal with it.
If I want to use dashes, thats up to me. If I want to use spaces,
thats my choice too. Now, if you want to reformat what I typed with
nice parentheses and dashes, thats your choice too - as long as what
you reformat it to is correct based on what I typed :)

Bottom line, the WORK should be on the programmers side - not the
users side.
Nov 22 '05 #3
I'm with Dan on this one. I'd include that the if your scheme does impose
some restriction, make sure that you have a clear example next to the text
box in a label or something that makes the requirements clear as day.
However, there are times that even with the documentation or examples, the
restrictions are ridiculous and still annoying. Having three or four
textboxes is another approach that's easier, so that the delimmiter doesn't
matter. Just make sure that the field auto tabs to the next one so that the
user doesn't have to hit tab if you use this method b/c it's really annoying
to have to tab twice or three times just to type in a number.

HTH,

Bill

--
W.G. Ryan MVP Windows - Embedded

www.devbuzz.com
www.knowdotnet.com
http://www.msmvps.com/williamryan/
"Earl comcast net>" <brikshoe<at.> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
I'm curious if there are others who have a better method of
accepting/parsing phone numbers. I've used a couple of different techniques that are functional but I can't really say that I'm totally happy with
either.

1. My first technique was to restrict the users to entries that could only
be 3 character, 3 characters, 4 character (area code, prefix, suffix,
respectively). I would null out any inputs that were non-numeric (except the backspace). This worked reasonably well, except it was somewhat ugly to look at.

2. My second technique was to give the user a single text entry box and
auto-format the string with hyphens as they entered the phone number. I then parse the phone number, knowing exactly where the hypens are located.

What I'm looking for is some better ideas. Anyone?

Nov 22 '05 #4
Interesting ideas.

In some earlier apps, I have already implemented the multiple text box
scheme (with auto-focus). I've rejected that approach for this one.

International codes are irrelevant to this particular app since the
customer's phone number must, by definition, be a U.S. resident. However I
did allow for this in the database design, as well as extensions, which
might be more relevant and more problematic.

I'm not terribly inclined to allow "numbers" such as 1-800-COLLECT for the
simple reason these are advertiser conversions that are transparent and
would have to be re-parsed even though the user should already know the
number (without another parsing, searching on an exchange would create other
difficulties). This is certainly do-able but I would expect business users
to be bright enough to figure out what the real number was. It is food for
thought though, and I will put that one in my notes for a later date.

It would be great to implement Dan's idea about allowing ANYTHING to be
entered. But I'm not convinced we can make structure out of non-structure.
It seems to me that there has to be some bare-bones structure to what a user
can enter.

Otherwise, do we not hit a point of diminishing returns by anticipating and
parsing every potential scenario? Or do we end up with a Telemagic database,
where users have failed to do some semblance of formatting and the system
just blindly accepts whatever was entered? Ditto for the Act! method of
dealing with phone numbers, which once again allows the user to enter
"free-form", but indeed does not deal with every concatentation and parsing
potential and thus ends up with some pretty screwball phone numbers. In
fact, I have yet to see one commercial product that has successfully dealt
with this issue to the point where a user can enter anything they would like
and have the system turn it into a viable phone number.

While these have been great ideas to get me to thinking, I think for now I'm
going to continue to use my latest method, where I allow the user to enter
whatever they want -- in a single text box -- but null out everything but
numerals. I auto-format a dash as the number goes in, then move them out of
the entry box when they hit 12 characters. Extensions are going to have to
be dealt with separately.

Thanks all for sharing your thoughts.

"William Ryan eMVP" <do********@comcast.nospam.net> wrote in message
news:ug**************@TK2MSFTNGP11.phx.gbl...
I'm with Dan on this one. I'd include that the if your scheme does impose
some restriction, make sure that you have a clear example next to the text
box in a label or something that makes the requirements clear as day.
However, there are times that even with the documentation or examples, the
restrictions are ridiculous and still annoying. Having three or four
textboxes is another approach that's easier, so that the delimmiter doesn't matter. Just make sure that the field auto tabs to the next one so that the user doesn't have to hit tab if you use this method b/c it's really annoying to have to tab twice or three times just to type in a number.

HTH,

Bill

--
W.G. Ryan MVP Windows - Embedded

www.devbuzz.com
www.knowdotnet.com
http://www.msmvps.com/williamryan/
"Earl comcast net>" <brikshoe<at.> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
I'm curious if there are others who have a better method of
accepting/parsing phone numbers. I've used a couple of different

techniques
that are functional but I can't really say that I'm totally happy with
either.

1. My first technique was to restrict the users to entries that could only be 3 character, 3 characters, 4 character (area code, prefix, suffix,
respectively). I would null out any inputs that were non-numeric (except

the
backspace). This worked reasonably well, except it was somewhat ugly to

look
at.

2. My second technique was to give the user a single text entry box and
auto-format the string with hyphens as they entered the phone number. I

then
parse the phone number, knowing exactly where the hypens are located.

What I'm looking for is some better ideas. Anyone?


Nov 22 '05 #5

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Earl | last post by:
I'm curious if there are others who have a better method of accepting/parsing phone numbers. I've used a couple of different techniques that are functional but I can't really say that I'm totally...
10
by: JackM | last post by:
I'm still working on validating the phone numbers that are entered on a form but have come across a problem I don't understand how to fix. I can handle most instances when it's in regular US...
3
by: venu | last post by:
Hi, I have a different requirement and it is : I need to validate a phone number field. It may or may not be a US phone number. The constraints are : *********************** # It should...
5
by: gvidak | last post by:
Hello Guys, Yes, another beginner in C++ and I have a homework assignment that is giving me a headache. Can someone help me with the following problem? I have a text file with names, phone numbers...
7
by: laredotornado | last post by:
Hi, Using php 4.4.4, I am looking to parse a US phone number string into 3 smaller strings -- area code, the first part of the phone number (3 digits) and the last part of the phone number (4...
4
by: lilOlMe | last post by:
I'd love to be able to validate phone numbers in my software but my product is being used world wide. Not everyone's phone number is formatted like USA/Canada formats theirs. I've found a few...
5
by: lim4801 | last post by:
I am currently in doing a program which is given by my tutor: Contemplate that you are working for the phone company and want to sell "special" phone numbers to companies. These phone numbers are...
4
by: Blue Streak | last post by:
Hello, Folks! Does anyone know of a website that lists the local phone number formats for each country? TIA...
7
by: Propoflady | last post by:
My contacts can have as many as five or six phone numbers - is it possible to make a query that puts the name, and each phone number after it on the same line - for this reason I have two tables -...
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.