Input Mask - 'Evil' and 'Not Useful'

Clifford

Thank you for your suggestion. I have fiddled with validation rules and have
got everything to work the way I want it to. By using validation, I can have
the variations that I want. Thanks again for all your advice. You helped me
solve my issue.

Chris

"Clifford Bass" wrote:

Hi Chris,

You are welcome!.

You may want to consider splitting the entry of the information into
separate text boxes, even if you rejoin it behind the scenes for storage in
the table.

Clifford Bass

"Chris Lines" wrote:

Clifford

Thank you. The masks I have used to date do indeed require extra key
strokes, so I see your point. But my inputers are regularly getting the input
format wrong (in my case it's a file-number format), which in turn means my
searches don't always give me the results I should get. I'm going to fiddle
with some validation rules and see how that goes. Thanks again, Clifford, for
your comments.

Chris

Hi Chris,

You are welcome. And continued good luck with that.

Clifford Bass

"Chris Lines" wrote:

Clifford

Thank you for your suggestion. I have fiddled with validation rules and have
got everything to work the way I want it to. By using validation, I can have
the variations that I want. Thanks again for all your advice. You helped me
solve my issue.

Chris

Just to throw a monkey wrench in the machinery...

I've actually had used Input Masks, primarily as a 'hint' to the
expected format and to avoid worrying about whether the user will enter
format inconsistently (e.g. 111-222-3333, 111.222.3333 or (111) 222-3333
all are valid formats) which would complicate my parsing (not so much
for phone numbers as a simple check of IsNumeric will suffice but for
mixed numbers and text, forget it).

However in cases where I've used input masks, I usually have VBA code
driving to determine the input mask. For example, in one project we
decided it made more sense to input all contacts for people in a single
contact tables with a combobox to identify what kind of contact it could
be. This could be either phone number (actually several variations of
phone numbers; mobile, home, work, fax) or email. Whenever the user made
a selection for an email, the input mask would be removed and the
validation rule would be to check for the usual @ and tld. Otherwise,
the input mask for phone number would be present giving my users the
advantage of entering the phone number with keypad without worrying
about formatting it themselves.

With ZIP code, it's same principle; we had to track both US and Canadian
addresses so we had an combobox to identify an address as US or Canadian
then apply correct input mask at runtime. Now, that is obviously a
different pie from the input mask as a property of table/fields as I've
been describing input masks as properties of controls on form which also
can be altered at runtime as described above.

Hopefully that's some food for thought.

Clifford Bass wrote:
Hi Chris,

You are welcome. And continued good luck with that.

Clifford Bass

"Chris Lines" wrote:

Clifford

Thank you for your suggestion. I have fiddled with validation rules and have
got everything to work the way I want it to. By using validation, I can have
the variations that I want. Thanks again for all your advice. You helped me
solve my issue.

Chris

Hi,

And I just recommended an input mask for someone else. It just goes to
show that generalizations have their exceptions.

Clifford Bass

"Banana" wrote:

Just to throw a monkey wrench in the machinery...
[snip]

On Tue, 22 Sep 2009 10:15:02 -0700, Clifford Bass
wrote:

Hi,

And I just recommended an input mask for someone else. It just goes to
show that generalizations have their exceptions.

Clifford Bass

"Banana" wrote:

Just to throw a monkey wrench in the machinery...
[snip]

All generalizations are flawed... including this one.
--

John W. Vinson [MVP]

Banana

Thank you for your thoughts. I appreciate it. I'm learning that there are
lots of differnent views and a variety of ways of doing the same thing.
Thanks again for your thoughts.

Chris

"Banana" wrote:

Just to throw a monkey wrench in the machinery...

I've actually had used Input Masks, primarily as a 'hint' to the
expected format and to avoid worrying about whether the user will enter
format inconsistently (e.g. 111-222-3333, 111.222.3333 or (111) 222-3333
all are valid formats) which would complicate my parsing (not so much
for phone numbers as a simple check of IsNumeric will suffice but for
mixed numbers and text, forget it).

However in cases where I've used input masks, I usually have VBA code
driving to determine the input mask. For example, in one project we
decided it made more sense to input all contacts for people in a single
contact tables with a combobox to identify what kind of contact it could
be. This could be either phone number (actually several variations of
phone numbers; mobile, home, work, fax) or email. Whenever the user made
a selection for an email, the input mask would be removed and the
validation rule would be to check for the usual @ and tld. Otherwise,
the input mask for phone number would be present giving my users the
advantage of entering the phone number with keypad without worrying
about formatting it themselves.

With ZIP code, it's same principle; we had to track both US and Canadian
addresses so we had an combobox to identify an address as US or Canadian
then apply correct input mask at runtime. Now, that is obviously a
different pie from the input mask as a property of table/fields as I've
been describing input masks as properties of controls on form which also
can be altered at runtime as described above.

Hopefully that's some food for thought.

Clifford Bass wrote:
Hi Chris,

You are welcome. And continued good luck with that.

Clifford Bass

"Chris Lines" wrote:

Clifford

Thank you for your suggestion. I have fiddled with validation rules and have
got everything to work the way I want it to. By using validation, I can have
the variations that I want. Thanks again for all your advice. You helped me
solve my issue.

Chris