Error 2110 Microsoft Access can't move the focus to the control Salutation

[woohoo30ca]

I have a form "frmQryIndividual" which contains a subform "frmNotes".

I've been looking everywhere at this error code. The problem I have, is that the majority of the time everything works. Once in a while, there's a run of entries on the subform that when you click on the parent form "frmQryIndividual" the error is thrown. Debugging the error takes me to the code that I have on the parent form...

Private Sub Detail_Click()
'This section recognizes the click on the main from after working in the sub-form and sets the focus back to the salutation field
Forms("frmQryIndividual").SetFocus
Me.Salutation.SetFocus
End Sub

So what happens, is that once a user finishes entering a note into the memo field on the subform "frmNotes" the can click in a blank area of the parent form and the focus is set on the Salutation field (which is visable), then the user can click on the close button on the main form.

For some reason at times, this just doesn't seem to work. I thought it would be some bad characters in the memo field on the subform "frmNotes", but that doesn't seem to be the case.

Like to see if someone has encountered this error only on occasion and if they might be able to guide me to what I can look at for an intermittent error 2110

 

[sneuberg]

According to this WEB site when that error occurs it could be

1. The control may be a type that can't receive the focus, such as a label.
2. The control's Visible property may be set to No.
3. The control's Enabled property may be set to No.

So you could change the code as shown below and find out what the status of these are when this occurs. Note that a textbox is type 109.

Private Sub Detail_Click()
On Error GoTo Detail_Click_Err

'This section recognizes the click on the main from after working in the sub-form and sets the focus back to the salutation field
Forms("frmQryIndividual").SetFocus
Me.Salutation.SetFocus


Detail_Click_Exit:
    Exit Sub

Detail_Click_Err:
    
    If Err.Number = 2110 Then
        
        Debug.Print Me.Salutation.Enabled
        Debug.Print Me.Salutation.Visible
        Debug.Print Me.Salutation.ControlType
        
    End If
    
    MsgBox Error$
    Resume Detail_Click_Exit


End Sub

I'm not sure what happens if Access doesn't see the Salutation control at all. If these Debug.Print statements raise an error you could end up in a infinite loop. Just kill the app in the Task Manager

 

[missinglinq]

Don't really understand why you need to go to the Salutation control before Closing the Form, but the problem, I'm sure, is with the line

Forms("frmQryIndividual").SetFocus

It's not that Access "can't move the focus to the control Salutation," but rather that it can't move the Focus to the Form!

In order for a Form to receive Focus...it has to contain no Controls that can receive Focus! Odd, I know, but that's the rule! And since you have at least one Control, on frmQryIndividual, that can receive Focus, the Form itself cannot, and hence the Error 2110.

It's doubly confusing, I'm guessing, because I'm sure that you know that to go from a Main Form, to a Control on a Subform, you have to first set Focus to the Subform, then to the Control on the Subform. The secret, though, is that you're first setting Focus to the Subform Control...which is a Control on the Main Form...you are not setting Focus to the Form that resides on the Subform Control...and that's the difference!

Delete the above line and you should be set!

Linq ;0)>

 

[sneuberg]

Don't really understand why you need to go to the Salutation control before Closing the Form, but the problem, I'm sure, is with the line

Forms("frmQryIndividual").SetFocus

It's not that Access "can't move the focus to the control Salutation," but rather that it can't move the Focus to the Form!

In order for a Form to receive Focus...it has to contain no Controls that can receive Focus! Odd, I know, but that's the rule! And since you have at least one Control, on frmQryIndividual, that can receive Focus, the Form itself cannot, and hence the Error 2110.

Delete that line and you should be set!

Linq ;0)>

I tried to simulate the OP's situation in the attached database and I can't reproduce the error. Please take a look at it and see if it's not what he described So I don't think the line

Forms("frmQryIndividual").SetFocus

is causing the problem. It's not in my simulation. But like you I don't understand why the OP thinks this is necessary. You can click a Close button in the main form without this intermediate step.

 

[gemma-the-husky]

@Linq

Without checking, I believe I have used simply formname.setfocus to activate a selected form.

Now I have reread the post, I think that line is the problem though. A subform is not a form that you can set a focus to, I don't think. The form does not exist in the applications forms collection, so you just need the right way to set the focus to a control on a subform

 

[woohoo30ca]

THanks to everyone who posted suggestions.

I think the problem is actually with the memMemo field on the subform (frmNotes)

This field is a memo field, yet when I get more than 2000 characters in the form I can't save the form (at times). If the total number of characters is under 2000 in this field, there is no problem, but if it's over 2000, sometimes the form will save other times it will puke.

What I did was add a 'save' button on the subform with the following code:
Private Sub btnSaveNote_Click()
Me.Refresh
End Sub

In this case I get a run-time error "3188" could not update; currently locked by another session on this machine.

If I ignore the 'save' button and click on the parent form (that I have been doing originally) I then get the error "2110" can't move the focus to the control Salutation (which is a combo box). Again, if the memMemo field has less than 2000 characters, I will not get any error if I click on the "save" button on the subform, nor do I receive any error if I click on the parent form.

I have found some information that Access apparently has problems with an edit buffer for memo fields in that it will not accept more than 2024 characters, otherwise you can get the 3188 error.

If I can find how to resolve this, I believe it will resolve the original 2110 error that I'm getting. :banghead:

 

[gemma-the-husky]

access actually has an absolute limit of 4000 bytes for a record, but this shouldn't include memo fields. not sure if you are hitting this limit.

 

[woohoo30ca]

I finally found tonight what is throwing the error 3188 and 2110. If I edit and go to update a memo in my subform (frmNotes), and that note that I'm editing happens to be the last record in the subform (i.e. 3 of 3) or (2 of 2) or (1 of 1) error 3188 or 2110 is thrown (depending on what action I take).

I get the 3188 error when I click on the save button that I added to the subform, thinking it was an issue on the way I was saving the record.

If I edit any other record in the subform other than the last record, the data is saved and I can go back to the parent form with no error 2110.

Is something possibly happening because of an EOF when trying to update data on my subform? This is the code I now have:

Private Sub btnSaveNote_Click()
If Me.Dirty = True Then
Me.Dirty = False
End If
With Me.Recordset
.Edit
!memNotes = !memNotes
.Update
End With

End Sub

 

[gemma-the-husky]

is the subforms cycle property set to all records or current record?
also check the tab order.

it might be that you are tabbing to the new record in certain circumstances, and then when you click the (unnecessary) save button the click event fails. maybe the me.recordset code doesn't do what you thing it does.

put some error handling in that sub to help identify why you are getting these errors.

 

[woohoo30ca]

It's been some time since I originally posted the problem in this forum.

I thought the issue was resolved but it has come back.

After turning off 'auto correct' and checking to see if record locking was turn on or off, I have noticed that I only get errors 2110 or 3188 when The note field on the subform happens to be the first note for the individual.

For instance,
If I have created three notes with a case name called
Topic1
Topic2
Topic3
Each with an associated note, the error only appears when I go to edit the note for Topic1

If I delete the record for Topic1 which would leave Topic2 and Topic3 with the associate note respectively, then editing the note for Topic2 produces the same error, yet editing a note for Topic3 is fine and if I add a new note called Topic4 and an associated note, editing the note for Topic4 is fine.

I have attached a screenshot of 'frmNotes' which is added to my form 'frmQryIndividual'
As you will see in the screenshot, the filed "Case" is an unbound field. On the subform, when I click on the combobox, the appropriate text in the "Notes" field appears - this is done from the "After Update" event on unbound "Case" field which fire off an embedded Macro (which you can see in the second attachment).

I'm guessing this embedded macro is the culprit