Chcek if Form Field Exists

  • Thread starter Thread starter Tim
  • Start date Start date
T

Tim

Hello,

Is there a function in access 2k that I can use to tell if
a form control exists. I am looking for something like:

bolExists = DoesExist(Me("Field_Name"))

I want to pass in a field name and get back a true or false
on whether it exists. Is there any way to do it? Thanks

Tim
 
I don't know how to do what you are asking, but depending
on what you are doing you may just want to capture the Run-
Time Error.


For instance:

Sub mySub

Dim missing as Boolean

On Error GoTo ErrorHandler

Me.Controls("Command1").Enabled = False

If missing Then
'Control not on Form
Else
'Control on Form
End if


ErrorHandler:
'Error 2465 = Microsoft Access can't find the
'field 'Command1' referred to in your expression.

If Err.Number = 2465 Then
'code for missing field
missing = True
End if

Resume Next

End Sub
 
bolExists = DoesExist(Me("Field_Name"))
Click to expand...

Public Exists( ControlName as String ) As Boolean
' Yes the On Error method works, but always strikes
' me as messy... This is probably slower (not tested)
' but "purer"!

' iterate the Controls collection
Dim ctl As Control

' Assume it's not there
Exists = False

' go round
For Each ctl in Me.Controls
If ctl.Name = ControlName Then
' found it
Exists = True
' don't go round any more
Exit For
End If
Next ctl

' all done
End Function



Hope that helps


Tim F
 
-----Original Message-----
' Yes the On Error method works, but always strikes
' me as messy... This is probably slower (not tested)
' but "purer"!
Click to expand...

I also thought of iterating over the controls, but wrote
the Error handling method instead.

Not that I am saying what you think is wrong, I'm just
curious as to why you think it's 'purer'?

Personally, I think people should write Error handling
code more often instead of trying to avoid it.
 
Thanks guys - I was hoping there might be a standard
function that did this, but I guess not. Makes it hard to
be lazy :) I also agree with Tim that writing your code so
that it throws an error just seems inelegant (though
sometimes its quicker and more compact). I like trying to
write code that prevents errors from occuring. Though both
methods do work fine - it's just personal preference.
Thanks again

Tim
 
I also thought of iterating over the controls, but wrote
the Error handling method instead.

Not that I am saying what you think is wrong, I'm just
curious as to why you think it's 'purer'?
Click to expand...

An interesting statement indeed. After all, this 'error' is just a
signal, and certainly in this case not one of failure.

Enumerating all controls has an average cycle count of half the amount
of controls; evoking an error has a cycle count of *one*. I like that
better...
 
I also thought of iterating over the controls, but wrote
the Error handling method instead.

Not that I am saying what you think is wrong, I'm just
curious as to why you think it's 'purer'?

Personally, I think people should write Error handling
code more often instead of trying to avoid it.
Click to expand...

While I often use the error trapping approach myself, many people object to
it because it implies tying your code to implicit error codes. For example,
currently you'll get an error 2465 if the control name doesn't exist in the
Controls collection. What happens to your code, though, if that error number
changes at some time in the future? (Yes, I realize that due to how
applications are written, it's extremely unlikely to ever change, but it is
possible)
 
An interesting statement indeed. After all, this 'error' is just a
signal, and certainly in this case not one of failure.
Click to expand...
For me, it's purely aesthetic, and I would never dream of describing any
code that uses the other approach as 'wrong'. We all have our tastes.

Incidentally, does anyone fancy benchmarking the two methods? Just because
the Error happens effortlessly from the point of view of the VBA programmer
doesn't mean it's quicker than a string comparison. Don't forget that
calling Me.Controls("txtEric") still requires some kind of iteration of the
controls collection, so it's probably not far off the explicit trip. Just a
thought...

All the best


Tim F
 
Tim said:
Incidentally, does anyone fancy benchmarking the two methods? Just because
the Error happens effortlessly from the point of view of the VBA programmer
doesn't mean it's quicker than a string comparison. Don't forget that
calling Me.Controls("txtEric") still requires some kind of iteration of the
controls collection, so it's probably not far off the explicit trip. Just a
thought...
Click to expand...

Interesting. I'll keep that in mind.

The 'some kind' of iteration, though, is likely to be Microsoft
Optimized ( I don't know the exact standard ;-) ) and runs below
interpretation level. Explicit looping eats up a lot of resources and
has this ugly O(n) behavior.

Nlh, I'll test that some day.
 
Back
Top