Checking a field for a value when the field might be empty

Working in this instance with Forms, but I suspect could be applicable to cells and maybe other.

In this instance there is a group of vba commands that need be executed if a textbox has a value over 24. It is also possible that the textbox is empty.

Presently I am doing:

Please Login or Register  to view this content.

Because, as you know, if I try:

Please Login or Register  to view this content.

I will get a "Type Mismatch" error triggered by "frmA.tbA * 1" if frmA.tbA is empty.

Is there a way to make the two conditions run from one control line of code? The problem is when I am forced into nested "If"s that all can be empty or have a threshold that must be evaluated.

As always, Thank-You very much for you consideration!

Doesn't seem to work for me, if I read you right. I get the same "Type Mismatch" when I try:

Please Login or Register  to view this content.

About the only thing I have found so far involves creating variables and basically:

Please Login or Register  to view this content.

I would like to avoid creating and then substituting variables for evaluation if something like I think you were advising and I wrote in the first code-box would work!

@MarvinP: frmA.tbA was simply my shorthand for a Form named "A" and a TextBox that resided in that form that I also happened to name "A"; I see my attempt to be concise easily lead to confusion! Basically, and again endeavoring to be concise but this time a little more understandable, envision a form with only one textbox. That textbox could be empty or could have a numerical value. That textbox is being evaluated in VBA. In my example I multiply the contents by 1 as that automatically causes the figure, if present, to be treated as a number in the VBA equation/evaluation, as you well know. But if that textbox is empty, Excel throws the error. Because I am working with multiple nested "If" statements/controls, to first test for whether or not TextBox evaluates to vbNullString would dictate/necessitate a full "If-Else-End If" construct for that, and then a partially repetitive with significant variances in the commands full "If-Else-End If" construct for the value that the TextBox contained, if such was the case.

As to the nesting of multiple "If" statements, each time one "If" evaluates to being true, not only does it trigger a set of commands but it also triggers the evaluation of another "If" statement. At any time when an "If" statement evaluates to False, a set of commands are triggered and the entire rest of the chain of nested "If"s are skipped.

I could break each "If" out on its own and come up with some additional evaluation as to whether or not that "If" should run, but I was trying to accomplish this as neatly as I could within a tree structure.

If each textbox being evaluated had a value, this would be a relatively simple process, and if I was comfortable with forcing a value of "0" in any empty textbox, that would also make it simple, but I need there to be a difference in the form between displaying a "0" where a "0" should be, and an empty box that has yet to be evaluated by either the user or by code.

Though I have made a number of naming substitutions and evaluation statements so I don't get the club I am doing this for upset with me, the following is the exact structure of one of the evaluation trees (yeah, there are a lot more items than one simple textbox involved... I present it simply to attempt to show the level of complexity (above one textbox) as it is much like a basic AI system applied for displaying or hiding items on the form. Note that each item evaluated would cause a crash if it is vbNullString. I suspect variable substitution for field evaluation prior to running the body of present code is my only option):

Please Login or Register  to view this content.

@bakerman2: Interesting use of the ":", I hadn't considered this. One complication that still would remain is that I do need to process alternate ("Else") instructions if TextBox1 is vbNullString. I will have to think about this.

Thank-you both VERY much for considering my problem! What is sometimes most embarrassing is that I occasionally create a problem for myself when there is another way to handle the entire situation; just hoping I am not going down that road again...