Hacker’s Guide to Visual FoxPro
An irreverent look at how Visual FoxPro really works. Tells you the inside scoop on every command, function, property, event and method of Visual FoxPro.
OLERequestPendingTimeout, OLEServerBusyRaiseError, OLEServerBusyTimeout
Microsoft certainly wasn’t miserly with the letters when naming these jawbreakers! They all have to do with how you manage delays and timeouts within your OLE Server application.
Usage
nPendingTimeout = oApp.OLERequestPendingTimeout
oApp.OLERequestPendingTimeout = nPendingTimeout
nBusyTimeout = oApp.OLEServerBusyTimeout
oApp.OLEServerBusyTimeout = nBusyTimeout
lRaiseError = oApp.OLEServerBusyRaiseError
oApp.OLEServerBusyRaiseError = lRaiseError
|
Parameter |
Value |
Meaning |
|
nPendingTimeout |
Positive number |
The amount of time in milliseconds to wait before displaying a message that the application is busy. |
|
Zero or negative |
No message is displayed. |
|
|
nBusyTimeout |
Numeric |
The amount of time to wait (in milliseconds) before raising an error if OLEServerBusyRaiseError is .T. |
|
Zero or negative |
No error is raised. |
|
|
lRaiseError |
.T. |
Create an error if an OLE request waits longer than the OLEServerBusyTimeout specified delay. |
|
.F. |
Don't error if the request is not answered in time. Without an error message, your application appears to hang. |
We find these settings a little confusing because their names don’t make clear the differences between them. The Request setting dictates the response to a user request, like clicking on a button or form. The ServerBusy settings affect how VFP reacts if program code can’t continue because a server is busy. Note, also, that both situations apply only if VFP is trying to work with a COM server in a separate process space—an EXE, not a DLL—and that you get no timeout errors if VFP is working with an in-process, DLL COM server.
OLERequestPendingTimeout is the amount of time delay after a mouse click or key is pressed before displaying “The action cannot be completed because the other program is busy. Choose ‘Switch To’ to activate the busy program and correct the problem.” The default is 5 seconds. We think that failing to respond to a user request is a cardinal sin among UI no-no’s, and we prefer to crank this down to 500 milliseconds or so.
OLEServerBusyTimeout and OLEServerBusyRaiseError work together to determine the behavior an application should take if a request to an OLE server is rejected because the server is busy. After the amount of time specified by the Timeout, VFP will raise an error if …RaiseError is set to true, or not. This error is not in the form of a VFP error as we had hoped, nor an OLE error, but rather the same old “This action cannot be completed…” dialog. We think that’s lame. If we need to create a COM server and expect sub-five-second response time, we want the process to fail and let us know we can’t get it. That would give VFP control and developers the chance to do something about it.
Example
_VFP.OLERequestPendingTimeout = 500 && half a second
_VFP.OLEServerBusyTimeout = 5000 && five seconds
_VFP.OLEServerBusyRaiseError = .T. && let operator know