How to require and check for two digits.

[Guest]

I have a textbox that I have set an Input mask of 00;;_ for a two digit
station number.

I check the range of the entry to ensure it is between 1 and 99, but I want
to display my own error message when the user only enters 1 of the required 2
digits.

Cheers

 

[Guest]

Loose the input mask. They are more trouble than they are worth. There are
two places this can be done - the Before Update event of either the text box
or the form. Check the value of the entry and present your own message box
if it is not correct:

If Not IsNumeric(Me.MyTextBox) Then
MsgBox "Only Numbers Allowed"
Cancel = True
ElseIf Len(Me.MyTextBox) <> 2 Then
MsgBox "Must Be 2 digits"
Cancel = True
End If

 

[Guest]

Thanks.....

There must be an easier way to search for these solutions. I have several
books and by far this forum beats out the books. It constantly amazes me as
to how many different ways there are to do things. Can anyone recommend a
good reference to learn all the difference syntax such as Len(me.textbox) or
IsNumeric(Me.textbox)

Cheers

 

[Guest]

Get on the "Function a Day" Plan.
Open up VBA Help.
Pick a Function you have never used.
Read the description and the example.
Think about how it might be useful.
Open the Immediate window.
Play with it.

As to books, there are a lot of books. Each author has his own way of doing
things, so each book will have a bias. The other problem is, unless the book
is VBA specific, it will probably not approach the subject at a detail enough
level. I usually shop the bookstores, open up one and see if I can
understand it and if it has something I can learn.

Coding is like any other skill, time in the barrel.

 

[Brian Wilson]

I have a textbox that I have set an Input mask of 00;;_ for a two digit
station number.

I check the range of the entry to ensure it is between 1 and 99, but I
want
to display my own error message when the user only enters 1 of the
required 2
digits.

Cheers

I agree with klatuu that input masks are more trouble than they are worth.
However if I wanted to enforce this, I would enforce it at database level,
rather than through code.
If these are codes that have some meaning that could be put into words, then
you could create a related table of codes adding all one hundres values with
the description next to each. Then you enforce referential integrity -
which means any entry must match one of your pre-defined codes '01', '02',
'03', etc
If this doesn't sound suitable, then just create a validation rule on the
table to say that the field must be:
Like "##"

These solutions mean that it is impossible to enter unacceptable data,
whereas writing code can only do it's best to prevent this happening.

 

[stefan hoffmann]

hi,

Get on the "Function a Day" Plan.
Open up VBA Help.
Pick a Function you have never used.
Read the description and the example.
Think about how it might be useful.
Open the Immediate window.
Play with it.

If you like to play such a hand slow

I like the following approach:
Take a closer look at specific function using the help and google for
it, if you're not sure about its complete scope.
Follow the links. Follow the links. Follow the links.)

Memorize the key concepts, cause you will benefit from it sooner or
later. It's worth its price.


mfG
--> stefan <--

 

[Guest]

Sorry, Brian, but I have to disagree with both of your ideas.
Why carry around a table with nothing more than 00 - 99 in it when a simple
code test will resolve it. The code test is much faster than a database
fetch. I also don't think this has anything to do with database integrity.

As to the field level validation. I never use it. First, you will be right
back to the problem of presenting you own error message. Sure, you can use
the Validation Text, but you don't have the same level of control over what
happens next. And second, should you ever have to upsize the database, I
don't know if there are any that an Access field or table level validation
rule or text can be translated to.

 

[Guest]

Yes, your input is a useful addition; however, you can read everything ever
written about driving a race car, but until you get behind the wheel and go
around the track, you can't drive a race car.

 

[stefan hoffmann]

hi,

Sorry, Brian, but I have to disagree with both of your ideas.
Why carry around a table with nothing more than 00 - 99 in it when a simple
code test will resolve it. The code test is much faster than a database
fetch. I also don't think this has anything to do with database integrity.

This is correct, except it is a domain definition, in this case the
RDBMS should take care of this too.


mfG
--> stefan <--

 

[stefan hoffmann]

hi,

Yes, your input is a useful addition; however, you can read everything ever
written about driving a race car, but until you get behind the wheel and go
around the track, you can't drive a race car.

D'oh. But i've heard about that thing called steering wheel, and i will
have a clue about how to use it

mfG
--> stefan <--

 

[Brian Wilson]

Sorry, Brian, but I have to disagree with both of your ideas.
Why carry around a table with nothing more than 00 - 99 in it when a
simple
code test will resolve it. The code test is much faster than a database
fetch. I also don't think this has anything to do with database
integrity.

As to the field level validation. I never use it. First, you will be
right
back to the problem of presenting you own error message. Sure, you can
use
the Validation Text, but you don't have the same level of control over
what
happens next. And second, should you ever have to upsize the database, I
don't know if there are any that an Access field or table level validation
rule or text can be translated to.

Of course all ideas have pros and cons and it is probably good that the OP
sees a range of solutions. However, you seem to have missed the fact that I
was only suggesting creating a related table if 'these codes had meanings
which code be put into words'. So if these were codes for the accounts
department to analyze expenses where "24" was paper, "25" pens and "26"
pencils, etc then it might make sense to have the related table.

Obviously I don't know if that is the case - but the suggestion is there if
this is appropriate.

As to the second suggestion, I personally would prefer the validation rule
to enforcing with a code-only solution. Perhaps you would also set the
length to 255 and try to enforce the maximum length by writing code, but I
would feel safer in knowing that there was a limit of 2 characters specified
in the table definition. In the same way, I feel safer knowing that a rule
of <Like "##"> means that whatever form I add, whatever code I change, I
will not and can not break this rule.

I agree that you may want to catch the error and write your own text rather
than the simple validation text, but at least you can be sure you get the
right data. If the database has only one data-entry form and nobody will
ever enter data in any other way or find another way to screw things up for
you, then you might want to rely on the code-only solution, but at least the
OP has an alternative perspective to consider.