Freakazeud, Im stuck

[Guest]

Method or Data Member not found for .SetFocus
any suggestions?

 

[Guest]

Hi,
that is wierd.
Maybe try to check your references...open vba editor, go to
tools--references and check if any are marked MISSING. Also check if you have
ADO reference set.
HTH
Good luck

 

[Dirk Goldgar]

Method or Data Member not found for .SetFocus
any suggestions?

Did you remember to change the names "YourCombo" and "YourMemoControl"
in freakazeud's code to the names of your controls?

 

[Guest]

None are missing, and i don't even see the ADO Reference. VB 6.3

 

[Guest]

ADO is set, i looked right over it. Im hitting a wall here.

 

[Guest]

This is what she looks like:

If Me.Combo689.Value = "Waived" And IsNull(Me.Comments1) Then
Cancel = True
MsgBox ("Course Waived - Explanation and Who Approved WAIVE, Required in
Comments/Waived Approval Field")
Me.Comments1.SetFocus
End If

 

[Dirk Goldgar]

This is what she looks like:

If Me.Combo689.Value = "Waived" And IsNull(Me.Comments1) Then
Cancel = True
MsgBox ("Course Waived - Explanation and Who Approved WAIVE, Required
in Comments/Waived Approval Field")
Me.Comments1.SetFocus
End If

Make sure that "Comments1" is the name of the text box on the form, not
just the name of the field.

 

[Guest]

Hi, Matt.

As Dirk Goldgar pointed out elsethread, you're getting the compile error
because you're using the same name for the control as you are for the field.
"Me.Comments1.SetFocus" means "use the SetFocus method of the Comments1
Property of this form." (If the form doesn't have a Comments1 Property, then
Access will use the control of this name.) Of course, the form _has_ a
Comments1 Property, but this property doesn't have a SetFocus method.
However, a text box has a SetFocus method, but since you didn't tell Access
to use the text box control named Comments1 instead of the form property
named Comments1, Access won't be able to figure out the ambiguity of this
name.

To avoid this common bug, either rename every control that the Wizard
creates for you if it is going to be used in VBA code, or in the Properties
dialog window, or in a query, or else always use the bang operator when
referring to controls in VBA code. For example, either of the following
would work:

Me!Comments1.SetFocus

or

Me.txtComments1.SetFocus

.. . . where the Wizard-named Comments1 control bound to the Comments1 field
is renamed as txtComments1. And I'd also highly recommend using descriptive
names for your controls. If there are hundreds of controls on a form, it's
hard to find, edit and understand code for combo689, but cboCourseStatus
would be much easier on whoever maintains this database application.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
See http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.

- - -
If my answer has helped you, please sign in and answer yes to the question
"Did this post answer your question?" at the bottom of the message, which
adds your question and the answers to the database of answers. Remember that
questions answered the quickest are often from those who have a history of
rewarding the contributors who have taken the time to answer questions
correctly.

 

[Dirk Goldgar]

"'69 Camaro" <[email protected]_SPAM>
wrote in message

Hi, Matt.

As Dirk Goldgar pointed out elsethread, you're getting the compile
error because you're using the same name for the control as you are
for the field. "Me.Comments1.SetFocus" means "use the SetFocus method
of the Comments1 Property of this form." (If the form doesn't have a
Comments1 Property, then Access will use the control of this name.)
Of course, the form _has_ a Comments1 Property, but this property
doesn't have a SetFocus method. However, a text box has a SetFocus
method, but since you didn't tell Access to use the text box control
named Comments1 instead of the form property named Comments1, Access
won't be able to figure out the ambiguity of this name.

To avoid this common bug, either rename every control that the Wizard
creates for you if it is going to be used in VBA code, or in the
Properties dialog window, or in a query, or else always use the bang
operator when referring to controls in VBA code. For example, either
of the following would work:

Me!Comments1.SetFocus

or

Me.txtComments1.SetFocus

. . . where the Wizard-named Comments1 control bound to the Comments1
field is renamed as txtComments1. And I'd also highly recommend
using descriptive names for your controls. If there are hundreds of
controls on a form, it's hard to find, edit and understand code for
combo689, but cboCourseStatus would be much easier on whoever
maintains this database application.

Hi, Gunny.

I've never had a problem using code like

Me.Comments1.SetFocus

provided that "Comments1" is the name of a control on the form, and
either (a) there is no field named "Comments1" in the form's recordset,
or (b) the control named "Comments1" is bound to the field named
"Comments1". Are you sure there is a bug related to this? You'll have
to convince me.

Many people do argue that you should always rename controls so they
don't have the same names as the fields they're bound to. I don't
agree, though. I find it worthwhile to maintain the logical unity
between a bound control and its controlsource, by leaving the control
named identically. I've never run into a problem with this. On the
other hand, I always rename unbound or calculated controls from the
meaningless names that Access generates, as you recommended above. It
is also true that I usually use the "bang" notation when I am referring
to a control in code for the purpose of accessing its special properties
and methods, such as

Me!Comments.SetFocus
If Me!lstDepts.ListCount > 10 Then

but use the "dot" notation when I am concerned only with the value of
the field to which it's bound:

Me.Comments = "Watch this space!"

You can call me inconsistent if you want; I can take it.