Debugging Problems with Remote Applications
Be sure to debug the behavior of your remote application locally before installing it on a server and attempting remote access. Any time you recompile the application, it must be re-registered on the server and client machines, so you save a lot of time if you're sure the remote application is working correctly before you proceed to testing it for remote access.
While you are debugging an application that uses another ActiveX .EXE or .DLL, you might want to use late binding to connect to the component rather than early binding. Late binding establishes a reference to the component at run-time using the CreateObject statement. Early binding establishes the reference at design time through the References dialog box and uses the New keyword to create an instance of the object.
Early binding is faster, but the reference needs to be re-established every time you recompile the referenced component. After you've debugged the application, you can switch to early binding to receive the performance benefits that it provides.
After you've verified that your remote application runs correctly and can provide objects to other applications locally, install it on the server and register the application on the server and client machines.
Next, run the client application that uses the object from the remote application. If you've done everything correctly, the two applications will run smoothly. If there are problems with the network connection, software installation, or application registration you will receive a remote automation error. Here are some of the common errors and a description of the possible causes:
| Number | Error Message | Possible Cause(s) |
|---|
| &H800706ba | The RPC server is unavailable | The server name is wrong in the client machine's System Registry entry for the remote application. The remote application has shut down on the server. The remote application's.EXE file was not found on the server. |
| &H800706be | The remote procedure call failed. | Network connection to server was dropped or timed out waiting for a response. |
| 800706d1 | The procedure number is out of range. | The client referred to an item that doesn't exist in the remote application, but is mysteriously registered on the client machine. |
| &H800706d9 | There are no more endpoints from the endpoint mapper. | The Remote Automation Manager (AUTMGR32.EXE) is not running on the server machine. |
| &H8007801d | Library not registered. | The remote application is not registered properly on the server machine. |
Remote application can leave instances running on the server even after there are no more references from client applications. Be sure to check the Task Manager on the server to make sure the remote application ends when it should.
These "phantom" instances can cause problems installing new versions of the remote application on the server, consume memory, and cause incorrect data to be returned to clients in some cases.
If you notice that your remote application leaves instances running after all client applications have finished using it, check that the application is correctly de-referencing its own internal objects. The most common problem occurs when an application creates an instance of a hidden form, but doesn't destroy that instance when it is done. Listing 21.1 shows Class_Initialize and Class_Terminate event procedures that start an instance of a form and correctly destroy that instance before the object is destroyed[md]preventing a phantom instance.
Listing 21.1 - Initializing and Terminating an Object that Displays a Form
Private Sub Class_Initialize()
' Start an invisible instance of the form.
frmLaunch.Hide
End Sub
Private Sub Class_Terminate()
' Be sure to close the form when you're done.
Unload frmLaunch
End Sub