Problem checking textboxes for null

[Sharkiness]

Moderator
This thread has been moved. New questions should go into new threads.

Hi Guys,

I am completely lost, trying to get the code found in:
how-check-if-all-textboxes-form-null to work

I am trying the code but I keep getting the error;

'The object doesn't support this property or method'

Runtime error '438'.

        Dim ctl As control
        Dim check As Boolean
        
            check = True
              
        For Each ctl In Me.Controls
              If ctl.contoltype = acTextBox Then
                    If ctl.Value = "" Then
                     check = False
            End If
        
        End If
        
    Next ctl
    
            If check = False Then
            
            MsgBox "There is no information provided", vbOKOnly
            Me.lstResults.RowSource = ""
            Else
            ListSearchresults
            
            End If

The error flags

If ctl.contoltype = acTextBox Then

and when I hover over actextbox is states actextbox=109

What i want is when the search button is clicked, to make sure at least one text box has a value. if none have a value then to throw the error message and exit sub, other run the Listsearchresul ts sub.

Any help and guidance would be much appreciated.

[TheSmileyCoder]

It would appear you have a typo. Its called ControlType, not contoltype.

[NeoPa]

The clue is in the fact that the property is spelled with all lower-case letters. IntelliSense will fix that for you if it's recognised. Clearly, in this case it doesn't recognise what you've typed ==> Mistyped.

It's why creating items with all lower-case characters (such as [check]) is recommended against. That and Require Variable Declaration can help you to avoid such simple errors in future. Think of these ideas as tools to help you avoid them.

[patjones]

I forgot all about that thread, and yet it illustrates many good points.

One thing that I will say about IntelliSense is that it usually, but does not always, behave as you might expect it to. In the present case, where we defined "ctl" as a Control typed variable and then refer to "Value" as a method of it...IntelliSen se will not capitalize Value for you - presumably because the control type of "ctl" is arbitrary (it may describe a control that cannot have a value). Yet, the code will compile and execute just fine.

I also think that another crucial point, taken from the original thread, is that the If statements must be nested for this to work out properly. The first time that I tried to use code like this, it took me time to realize that the system evaluates both components of an AND even if the first component evaluates to False.

Pat

[NeoPa]

PatJones:
In the present case, where we defined "ctl" as a Control typed variable and then refer to "Value" as a method of it...IntelliSen se will not capitalize Value for you - presumably because the control type of "ctl" is arbitrary (it may describe a control that cannot have a value).

That's not accurate Pat. Intellisense will capitalise it for you unless you have somewhere redefined "Value". This can be done by dimming a variable for instance :

Dim value As Variant

After this the system will treat all .Value references as .value. One of the reasons that reusing known names for your items is also recommended against.

In fact, it will quite happily match case for any known names, whether or not they are valid properties of the object. Try using the following for instance (where txtName is a TextBox control) :

Me.txtName.querydefs = 3

Even though TextBoxes have no .QueryDefs property, it will be made to match .QueryDefs for you.

[patjones]

Correct you are. I got mixed up. When I tried it just now it does indeed capitalize "Value" for you. What it does not do is bring "Value" up in the list of methods for "ctl", an observation that fits in more naturally with what I was trying to say.

[NeoPa]

PatJones:
What it does not do is bring "Value" up in the list of methods for "ctl", an observation that fits in more naturally with what I was trying to say.

Indeed Pat. That also makes sense of course, as a Control object is almost as non-specific as a Variant (Which is what you seemed to be saying the first time round, to be fair). A reason for using such types only where the code needs to handle various different types of entities.

To say that another way, when dealing with a specific type of control, for instance TextBox, it makes more sense to use a variable of type TextBox. Only when dealing with different types of control does it make sense to use one of type Control. For this case it's valid to use the Control type for the variable, of course.