A 2950 error on a "SetFocus"!!!!!

[GraeagleBill]

I don't know if anyone else has hit the "famous" 2950 with a simple "SetFocus" and thought I'd post it for whatever value it might have to the forum.



(The sub where the "SetFocus" error occurred is charged with clearing some fields upon a "Cancel" function within the app. I moved the offending statement outside of the sub and the error went away.)

[Micron]

It's great that you give back to the forum, but I'm not sure how I could use this without knowing more, but I will try to remember your solution. By any chance did the clearing process also render the control as invisible, because if it did, you cannot set the focus to a control that is not visible? I see that some controls are becoming invisible as part of the process. No doubt it is not because of a mis-spelling of the control name.

[GraeagleBill]

No, "Me.tbNewDate" control was quite visible. Access will issue a specific error and explanation if one attempts to set the focus on a non-visible control. I have no idea why the error went away by just having moved the action to a equally suitable location in the code. This isn't the first time I've encountered a 2950 in A2003.
Bill

[Micron]

Thanks for the reply. Nice that you solved it, but we don't really know the cause. I've researched it and wonder if you're open to exploring the issue a bit?
Is there another event that is tied to the offending control?
Is this a 2003 db but the MS Access version is 2007? (trusted location issues)
Is it strictly vba code that's involved, or is a macro involved also? (macros not being trusted/allowed)
Is this a split form and/or has a datasheet (even one disabled control on a datasheet can cause this)
Maybe tbNewDate does not reside on the same form as the form whose code you show (incorrect subform or non-current form reference)?
I understand if you don't want to explore the issue any further and prefer not to elaborate, and I'm out of ideas at the moment.

[GraeagleBill]

Is there another event that is tied to the offending control?
tbNewDate has both an OnClick and OnChange events. The control is un-bound.

Is this a 2003 db but the MS Access version is 2007? (trusted location issues)
This app is in the 2000-2003 format and the run-time environment is A2003. The app is a mdb/mde split configuration.

Is it strictly vba code that's involved, or is a macro involved also? (macros not being trusted/allowed)
No macros involved. Strictly VBA code located in the code sheet of the form.

Is this a split form and/or has a datasheet (even one disabled control on a datasheet can cause this)
No. Simple continuous form with tb controls located in the footer of the form. tbNewDate control is in the footer section.

Maybe tbNewDate does not reside on the same form as the form whose code you show (incorrect subform or non-current form reference)?
No, there are no sub-forms involved in the particular app. In my experience, this form is about as "vanilla" as they come format wise.

[Micron]

Maybe tbNewDate does not reside on the same form as the form whose code you show (incorrect subform or non-current form reference)?
No, there are no sub-forms involved in the particular app. In my experience, this form is about as "vanilla" as they come format wise.

This one has me puzzled. I thought you could not have a datasheet view of a form and see a header or footer. I thought you had to have a main form with a datasheet in a subform control. I read that Access would automatically create a datasheet in such a way if there was a one to many relationship defined between two tables, so I created two such tables and used the form tool. Presto! I have a form with header/footer and a datasheet - in a sub form control. So if I am to dig any deeper, I have to know how you create a datasheet with a header/footer and have no subform involved.

[GraeagleBill]

datasheet view of a form and see a header or footer

Not right or wrong, but I'm not sure we have the same understanding of the terms "form" and "datasheet". Again, not right or wrong, but I think of "datasheet" as when I "Open" a table to view the records in the table. And no, in the case of "datasheet" there isn't any header or footer section. In the case of a "Continuous Form", I'm referring to the case where one has a header, detail and footer section that are populated with the various types of controls. E.g., text boxes, combo boxes, labels, etc. And, "Continuous" meaning that the detail section is populated with all records returned by either a query or table reference as being the RececordSource for the form.

In the current app we've been discussing, the offending control is in the footer section of the continuous form, something I've done in form design for years.

[Micron]

I think we have the same perspectives. I mis-read what you wrote and thought you were saying you had a datasheet on a form with a header and footer.
I though it might be because you were editing a record (by setting controls to Null) and can't set the focus because the record edit is still occurring - as if you were manually editing in a table or datasheet. However, I tested that and it works for me. The error basically means "Action Failed", which can be generated for a lot of reasons, but I can't figure yours out based on the code you posted. Thanks anyway.