OleServerBusyTimeout (VB6)

Topic

New Reply

Hi all,

When opening an office document that expects user interaction my app is hanging. I assume that using App.OleServerBusyTimeout and App.OleServerBusyRaiseError will somehow allow me to trap this.

The only problem is that I can’t work out how to raise an error after a certain amount of time.

The sample below tries to open a db with a compile error in the startup form, causing Access to ask for user intervention. What I want to do is wait 5-10 seconds and then close the database and move on.

Is this possible and am I looking at the wrong approach.

Note it could be word, access or excel that hangs.

After further reading, it looks like I am out of luck. It appears that once I have opened the app, I am comited. I must leave it visible and manually intervene if necessary.

Anyone have any other thoughts?

MS say
start Quote
For the component busy condition, you can bypass both the Component Busy dialog box and the replacement message by setting the Boolean OLEServerBusyRaiseError property of the App object to True. Visual Basic will retry your request for the length of time specified by the OLEServerBusyTimeout property, and then raise an error in the procedure that made the Automation request, just as if the user had pressed the Cancel button on the Component Busy dialog box.

The error returned is

Reply | Quote

Replies

I don’t know the solution for your problem. But looking at your code, I would suggest adding a line just before the End Sub:

Resume Proc_Exit

That way you create a ‘single point of exit’ where everything is cleaned up after an error is handled.

Reply | Quote

Thanks for taking the time to read and reply Jan.

That was just a sample of the type of thing I was looking for, in all honesty I don’t think that the code ever ran to completion, I kept killing it because my Automation Server just sat there and never generated the OleServerBusyTimeout Error that I was hoping for. Some days I just hate MS Office and MS in general. Other days im makes me say “Wow”. Such is life.

I generally try to always exit at the Proc_Exit: section or whatever the designated exit point is for the procedure.

Cheers

Stewart

Reply | Quote

Thanks for taking the time to read and reply Jan.

That was just a sample of the type of thing I was looking for, in all honesty I don’t think that the code ever ran to completion, I kept killing it because my Automation Server just sat there and never generated the OleServerBusyTimeout Error that I was hoping for. Some days I just hate MS Office and MS in general. Other days im makes me say “Wow”. Such is life.

I generally try to always exit at the Proc_Exit: section or whatever the designated exit point is for the procedure.

Cheers

Stewart

Reply | Quote

for anyone who is interested.

The Access conversion Reporting Tool was released. I downloaded it and looked with great interest to see how MS were going to handle this sort of scenario where the automation object fails to respond.

They shell out and run their converter/scanner exe.
They then get a handle to the app.
This allows them to kill the instance after time out or user cancel.

code snipits from scanner follow

        'build the command line, assume adscanner.exe is in my directory
        strCmdLine = """" & CurrentProject.Path
        If Right$(strCmdLine, 1)  "" Then strCmdLine = strCmdLine & ""
        strCmdLine = strCmdLine & "adscanner.exe"" "
            
            'calls out to the scanner tool
            lTaskId = Shell(strCmdLine, vbHide)
            If lTaskId = 0 Then
                MsgBox "Error launching AdScanner!", vbOKOnly, "Error"
                GoTo LExit
            End If
            
            hProcess = OpenProcess(SYNCHRONIZE, False, lTaskId)
            'if we can't get a process handle then assume adscanner is already done
            If hProcess Then
                'Keep waiting until the process ends or the user cancels
                Do While (WaitForSingleObject(hProcess, 0) = WAIT_TIMEOUT) And (fStopScanning = False)
                    'Wait a second before we try again.
                    dtNextTryDate = DateAdd("s", 1, Now)
                    Do
                        DoEvents
                    Loop Until dtNextTryDate <= Now
                Loop
                CloseHandle hProcess
            End If

Oh well when the MS programmers have to do it this way, there is no hope for me.

Stewart

Reply | Quote

for anyone who is interested.

The Access conversion Reporting Tool was released. I downloaded it and looked with great interest to see how MS were going to handle this sort of scenario where the automation object fails to respond.

They shell out and run their converter/scanner exe.
They then get a handle to the app.
This allows them to kill the instance after time out or user cancel.

code snipits from scanner follow

        'build the command line, assume adscanner.exe is in my directory
        strCmdLine = """" & CurrentProject.Path
        If Right$(strCmdLine, 1)  "" Then strCmdLine = strCmdLine & ""
        strCmdLine = strCmdLine & "adscanner.exe"" "
            
            'calls out to the scanner tool
            lTaskId = Shell(strCmdLine, vbHide)
            If lTaskId = 0 Then
                MsgBox "Error launching AdScanner!", vbOKOnly, "Error"
                GoTo LExit
            End If
            
            hProcess = OpenProcess(SYNCHRONIZE, False, lTaskId)
            'if we can't get a process handle then assume adscanner is already done
            If hProcess Then
                'Keep waiting until the process ends or the user cancels
                Do While (WaitForSingleObject(hProcess, 0) = WAIT_TIMEOUT) And (fStopScanning = False)
                    'Wait a second before we try again.
                    dtNextTryDate = DateAdd("s", 1, Now)
                    Do
                        DoEvents
                    Loop Until dtNextTryDate <= Now
                Loop
                CloseHandle hProcess
            End If

Oh well when the MS programmers have to do it this way, there is no hope for me.

Stewart

Reply | Quote

“When opening an office document that expects user interaction my app is hanging.”

in general, you could avoid user interaction by setting various properties before/at opening of an office document. maybe this can avoid the serverbusytime.
in word for example, you can aplly properties to autoconfirm conversions, disable automacros and so on, the same goes for excel.
in access, it is no problem if that database has an opening form afaict (at least in my limited testing), only when this form start running code immediately this could (not tested) lead to timeouts. also, have you considered using ADO to open the database instead of creating an access instance

Reply | Quote

“When opening an office document that expects user interaction my app is hanging.”

in general, you could avoid user interaction by setting various properties before/at opening of an office document. maybe this can avoid the serverbusytime.
in word for example, you can aplly properties to autoconfirm conversions, disable automacros and so on, the same goes for excel.
in access, it is no problem if that database has an opening form afaict (at least in my limited testing), only when this form start running code immediately this could (not tested) lead to timeouts. also, have you considered using ADO to open the database instead of creating an access instance

Reply | Quote