Error 438

[JamesJoey]

I've been using this code for years to add a record. Although it's been a while since I used it on this particular table and form.
The form is a split form.
Code:
DoCmd.GoToRecord , , acNewRec
Me!DvdMovieTitle.SetFocus

When I remark out the SetFocus line no error.
This same code, except for the field name, works fine on all of my other forms.
The filed is enabled and not locked. Ther name is correct.
I even checked several backups dating back for 2 months and I get the same error.

Any ideas?
James

 

[Minty]

Have you tried using

Me.DvdMovieTitle.Setfocus

I suspect you have a field called DvdMovieTitle but the control holding that data is called something else.
You can't set the focus to the Field, only the control.

 

[JamesJoey]

Now I get 'Method or Data member not found.

I have this cvode on another form and it works fine:
DoCmd.GoToRecord , , acNewRec
Me!Listing.SetFocus

I believe it was a corrupted form. (Which seems to be a recurring theme with me.)

I found a backup with the form from 4 months ago and the thing works fine.

 

[Minty]

You shouldn't really refer to form objects with the ! (bang) notation.

Try always using Me. (dot) as you will get an immediate notification that something is wrongly typed, and the benefit of Intellisense for a lot of the standard functions.

I'd be worried about continuous cases of corruption.

It might be worth doing a decompile or even import everything into a new blank database.

 

[Isaac]

I believe it was a corrupted form. (Which seems to be a recurring theme with me.)

This is just a list of things I've personally done to cause problems with my databases:

1) compacting & repairing too often generally speaking - just doing it over and over
2) compacting and repairing on the network
3) editing breakpoints or code while code is in break mode
4) running the code or the database without having compiled the code first, every time
5) hitting control+pausebreak too often to interrupt code

 

[JamesJoey]

I'll import into a new database. I really didn't think of trying that.

I do compact and repair frequently, especially if I'm making changes to all my forms.

Oh, well.
Thanks for the insights.

James

 

[Pat Hartman]

Just FYI, you don't need the setfocus statement if you want focus to be in the "first" control. "First" in this case refers to the tab order and first is the control with a tab order of 0 or the first unlocked control with the lowest tab order which could be 58 or whatever. When you rearrange controls, always update the tab order to keep the user from getting confused if he tabs through the controls.

 

[JamesJoey]

The problem with that is this is a split form. Without the SetFocus I'm forced to click in the first field even though it is the first control in the Tab Order. After clicking the 'New' button, the focus goes to the datasheet even though I set it to Read Only.

 

[JamesJoey]

Just wanted to let everyone know I found what caused the issue with the Error code 438.
Found that for some reason I changed the 'Name' of the control to 'Title.'
Still don't know why I would do that.
Changed the Name to DvdMovieTitle and it works fine now.

 

[Minty]

To avoid these issues in the future, and I know it's a bit of a PITA, but get into the habit of renaming your controls on forms. Use a naming convention. So the control would be called

If it's a textbox control - Field DVDTitle - control name txtDVDTitle
Combo box control Field EmployeeID - control name cboEmployeeID
listbox - lstYorFieldName

etc .etc.

This way you always know exactly what you are referring to, the control or the underlying field.
Unfortunately, if you use the form wizards or drag and drop the fields from the field list in the designer, Access defaults to calling them the same, which is a major headache.

 

[JamesJoey]

I use the naming conventions on combo boxes, list boxes and command buttons.
I guess it's just a matter of naming them properly.

 

[Minty]

I use the naming conventions on combo boxes, list boxes and command buttons.
I guess it's just a matter of naming them properly.

I have seen some VBA routines to go through and rename everything automagically, but if you have a lot of code it's a bit of a nightmare.

Good luck with the rest of your project.

 

[JamesJoey]

Thanks much,
James