Don't Understand Error Message

[OldBirdman]

This code is in a Module called from an _Click event for my form named fAAA. Variables beginning ix... are Global Long, declared elsewhere.

Public Sub QuickShow()
On Error GoTo QuickShow_Error
'Display Quick Dropdown ListBox
    If ixQuickLevel = 0 Then Exit Sub
    Forms!fAAA.cboQuick = Forms!fAAA.cboQuick.DefaultValue
    Forms!fAAA.cboQuick.ListRows = ixQuickCount
    Forms!fAAA.cboQuick.SetFocus
    Forms!fAAA.cboQuick.Dropdown
    Exit Sub
QuickShow_Error:
    Debug.Print Err.Number; Err.Description
    Debug.Print "List Rows=" & Forms!fAAA.cboQuick.ListRows
    Debug.Print "Enabled=" & Forms!fAAA.cboQuick.Enabled
    Debug.Print "Visible=" & Forms!fAAA.cboQuick.Visible
    Stop
    Resume Next
End Sub 'QuickShow

It stops at Line #15, displaying in the immediate pane

--2147417848 Method 'SetFocus' of object '_Combobox' failed
List Rows=3
Enabled=True
Visible=True

and if I step it, resumes at Line #8.

The form then seems OK, showing cboQuick with the dropdown list, but if I click an item in the list, Access closes completely, instantly. No warnings, no opportunity to save anything. Well almost completely. It does not close Help, nor does it delete the .ldb file. There is a Private Sub cboQuick_Click()
but that code is never entered.

If I click any other control except cboQuick, the dropdown does not close, it persists. It will persist even if I change to other windows, i.e. Windows Explorer.

What is going on?

[puppydogbuddy]

Hi OldBirdman,

What is going on is 2 things, the first is that you are encountering an error on the set focus code line (could there be nulls returned from the combobox?), and the second is that your code is terminating because the statement following Resume Next is End Sub.

To reiterate: Your code is encountering an error on line 7 (SetFocus), then the error is passed to the error handler. The error handling code is executed, resulting in the program execution being halted at line 15 when the Stop statement is executed. Then the resume next is executed , the next code line is the end sub.

[OldBirdman]

If error is ignored, and subroutine called again, Line #7 errors and the Debug.Print is

List Rows=4
Enabled=True
Visible=True
-2147417848 Automation error
The object invoked has disconnected from its clients. 

How can I have an "Automation error" with an object on the current form?

[OldBirdman]

Thanks for responding, puppydogbuddy. I missed this earlier as I was adding information with a simultaneous post to yours.

...first is that you are encountering an error on the set focus code line

Yes, I would agree with this.

could there be nulls returned from the combobox?

No, but even if there were, this is a .SetFocus to a control on the current form. The only reason it isn't Me.cboQuick.SetFocus is Me. can only be used in a Class Module.

...and the second is that your code is terminating because the statement following Resume Next is End Sub.

The code executes (at least when stepped) as Line 4, 5, 6, 7, 11, 12, 13, 14, 15, 16, 8, 9. Why would Resume Next, which is essentially a GoTo Line 11 not execute if followed by an End Sub? Removing Line 15 still displays the .DropDown, so the Stop doesn't affect the execution order.

resulting in the program execution being halted at line 15 when the Stop statement is executed.

When I say that Access closes, I don't mean the code is paused at a Stop Statement, I mean that the VBA Window closes, all my open forms close, the DataBase Window closes, the Access Window closes, and if I didn't have Windows Internet Explorer open, all I would see is my desktop image. No "Do you want to save?" msgbox. Restarting Access shows that the last access file in the filelist is not the one just closed.
Although Help is not closed with the rest of Access, it will take a computer re-boot to allow me to type in the Answer Wizard boxes or the Index Enter Keyword box.

[RuralGuy]

It may help to understand that errors in Access tend to invalidate Global Variables. Can you just comment out line 7 and have it function correctly? I do not believe the DropDown function requires the control to have the focus.

[missinglinq]

Afraid it does, Allan!

Linq ;0)>.

[puppydogbuddy]

Hi OldBirdman,
I was not thinking. You are correct about the Resume Next statement.... If the error occurred in the same procedure as the error handler, execution resumes with the statement immediately following the statement that caused the error. If the error occurred in a called procedure, execution resumes with the statement immediately following the statement that last called out of the procedure containing the error-handling routine (or On Error Resume Next statement).

In light of the above, the error occurs on line #7 (SetFocus error), it should resume next at line #8 (the dropdown statement). However, it can't resume at line #8 because the dropdown statement requires a setFocus on the combobox as Linq already stated. I believe this stalemate is what triggers Access to close. The only thing left to figure out is why you are getting the setFocus error on the combobox.

[RuralGuy]

@missinglinq
I am now wiser, kind sir.

[Stewart Ross]

Hi OB. I've not found anything on MSDN about error -2147417848 in an Access context; there are some knowledge base articles relating to command bars or the like, but none at all for the circumstances you mention.

However, there are references to error -2147417848 arising in the context of disconnection from automation objects (although in other applications). There is no one cause, but clashes between instances of installed OCX controls is mentioned in some cases.

I also found a knowledge base article specific to VB 5 and 6 forms (not Access or VBA) which describes that particular error occurring after a setfocus issue, the context being form controls passed as parameters outside the scope of current projects, but again this does not relate to your current circumstances.

As Access is crashing altogether, and none of us can reproduce the problem on our installations, it may be that you have some kind of clash between installed components in your installation, or perhaps a corrupt database of some kind, which is killing the application in circumstances where normal operation should continue.

Last year I had automation disconnection errors occurring in one form of a database which had been developed incrementally over a period of many years. It had been running fine with that form for over a year, started occurring suddenly but was every time thereafter, and its cause could not be traced by normal debugging. In my case this was a sudden internal database corruption of unknown nature, resolved by reverting to a known good back-up.

In this context, 'automation disconnection' does not relate to anything we do as developers - it seems to relate to the internal built-in processing performed by controls and forms in their normal operation.

I wish I could be of more help here, but this one does seem to be one of the really inscrutable errors...

-Stewart

[OldBirdman]

Thank you all for your attention.

Some comments on your responses. I have tried this with the cboQuick.SetFocus removed, and as expected, I get

2185 You can't reference a property or method for a control unless the control has the focus.

I have Googled the '2185' error before, when the control should have the focus, such as in the OnClick for that control. There are many forums found where this is asked, and almost all of them respond that the control must not be .Enabled, .Visible, or there is a mis-spelling. I added the Debug.Print to let anyone reading my post know that this was NOT the case.

It may help to understand that errors in Access tend to invalidate Global Variables.

I have to be careful when I proceed from the Stop statement because of this. Without the Stop, Access does not loose the Global Variables, but once it shows the VB code, the Global stuff is gone. What I posted is after about 50 tests of various combinations of Stops, Resumes, and such.

I have tried this on my laptop, Access 2002 instead of Access 2000, and I get the same -2147417848 message. Both machines re-booted with nothing else running (except all that stuff like virus protection that auto-starts). I've never even tried Automation, so don't see how that is involved.

This is an older database, but one that I have been working on continually. I was initializing this cboQuick with a procedure reference. This caused continual calls to the procedure any time any control focus was changed. Slowed down the whole project.

I wrote a new routine as a new project and got it working. I cannot reproduce the error under test conditions, so I'm not surprised that you can't.

Of course I can back up to the original (working) state, and try again. It will be my 3rd try. 1st try got the "2185" message that cannot set focus at the .SetFocus and I could not get around that.

[RuralGuy]

If you put this function in the form's class module, does it then work without error?

[DonRayner]

Hi OB; What happens if you comment out lines 5 & 6?

[OldBirdman]

If you put this function in the form's class module, does it then work without error?

This will involve a considerable amount of work, as many procedures are intertwined. I've spent 3 hours at it, and I'm making it worse. Do you have some reason to believe this might be an answer? If so, I'll pursue. If you're only fishing, I really don't know.

As I said in my previous post,

I wrote a new routine as a new project and got it working. I cannot reproduce the error under test conditions, so I'm not surprised that you can't.

I'm trying now to get this closer to the actual program, by moving the procedures to from class modules.

What happens if you comment out lines 5 & 6?

There is no difference, -2147417848 Method 'SetFocus' of object '_Combobox' failed with the same values for .Enabled, .Visible, etc.

[RuralGuy]

It sounds like you are zeroing in on the solution. I'll leave you alone for now.

[OldBirdman]

I'll eventually make it go away. I just wish that there were some documentation (Microsoft should do) regarding this message. Once gone away, there is no guarantee that it will stay gone. I've had these things come back and bite me.

Thank you all for your mental efforts.

[OldBirdman]

My project needs a ComboBox (cbo) that could contain 2,500 rows, 50 bytes/row. Probably never this big, but I have to program for it. Because cbo.RowSourceType = Value List limits the length of cbo.RowSource to 2048 bytes, I chose to use a procedure to fill the rows.

This solution appeared to solve my problems, but Access continually ran the initialization procedure. Every time any control on the form, or any form in the project, changed, Access was running the initialization. I understand running enough to display to cbo.ListRows, and then finishing later, but continually?

I then came up with different logic to do the same thing, and could work with the 2048 byte limits. So I changed cbo.RowSourceType to Value List, and wrote the code to build the list and assigned it to cbo.RowSource. The results were "-2147417848 Automation error", which I became fixated on, and posted here.

After much trial-and-error, it turns out that the problem was cbo.RowSourceType = Value List, done in Design View in the properties box. Making only this change caused strange problems.

The background color of textboxes would change when the control got focus, and remain changed/wrong even after lost focus. Didn't matter bound or unbound. Comboboxes would also change color, and the item selected would not display. Bound or unbound. If bound, and moving to another record and back, the change had been made, just not displayed.

Attempting to change to Design View always terminated Access without warning.

Eventually I just deleted the cbo, saved, and exited Access. Re-entered and created a new cbo from scratch. Controls are acting as I want them to. No strange messages, no problems with SetFocus.

I know this is wordy, but I thought you would want to know.

[RuralGuy]

Thanks for posting back with your success, OldBirdman. It will help others I'm sure.