HOWTO: Debugging Remote Automation Servers in Visual FoxPro 5

• Microsoft Visual FoxPro for Windows, version 5.0

SUMMARY

This article discusses general directions on how to debug remote server applications.

MORE INFORMATION

Visual FoxPro 5.0 allows you to create remote OLE Automation servers. Unlike servers deployed locally, which can either be an .exe file or a .dll file, remote servers must have an .exe file extension. One of the advantages with .exe type servers is that they have their own event loop, so you can process events. However, in a typical remote situation, your server is non-visual (typically a business object in a three-tier situation).

Debugging your .exe servers should be straight forward. For the most part, you should be able to test your servers locally before deploying them remotely. Most of the servers run the same in both situations. The approach you should take in creating and debugging a remote server is as follows:

1. Create your server as an internal Visual FoxPro class. Assuming you have a project called Books, which has a custom class called taxes that calculates the state/province sales tax for your mail order book sales business, you might have your class loosely structured as follows:

         * TaxLib.PRG
         DEFINE CLASS taxes AS custom
         PROCEDURE gettaxes
            LPARAMETER cState
            DO CASE
            CASE m.cState = "CA"
              RETURN .08
            CASE m.cState = "WA"
              RETURN .07
            CASE m.cState = "NY"
              RETURN .10
            OTHERWISE
              RETURN 0
            ENDCASE
         ENDPROC
         ENDCLASS
   
      Your application can test this class within Visual FoxPro internally
      with code similar to the following:
   
         cState = "CA"
         nBookPrice = 19.95
         SET PROCEDURE TO TaxLib    && can also use SET CLASS
         oTaxes = CreateObject("Taxes")
         nBookTax = oTaxes.GetTaxes(m.cState) * m.nBookPrice
         ? "Book total: "+ALLTRIM(STR(m.nBookPrice+m.nBookTax))
   
      The advantage here is that you are working within the Visual FoxPro
      development environment so you can take advantage of the debugger for
      common errors such as "Syntax Error."
   
   

2. Change you class definitions to OLEPUBLIC and test locally. Theoretically, you have already debugged for most of the common errors. Now, you want to test the class as an OLE Server. In order to do this, update the class definition to make it OLE Public and rebuild the project, selecting the Build EXE option. The following shows this using a class defined in a .prg file:

   Change:

         DEFINE CLASS taxes AS custom
   

   To:

         DEFINE CLASS taxes AS custom OLEPUBLIC
   

   NOTE: If you are using a visual class created in a .vcx file, you would go into the Class Info dialog box to select the OLE Public check box.

   Once you have created your OLE Automation Server, you can update your test code as follows (notice that you no longer need a SET CLASSLIB or SET PROC statement--the class is automatically registered in the Registry as an OLE class):

         cState = "CA"
         nBookPrice = 19.95
         oTaxes = CreateObject("Books.Taxes")
         nBookTax = oTaxes.GetTaxes(m.cState) * m.nBookPrice
         ? "Book total: "+ALLTRIM(STR(m.nBookPrice+m.nBookTax))
   

   You should not encounter many problems beyond step 1; however, there are a few things to look out for. Since the OLE Server uses the run-time version, not all the language is supported (especially some of the user interface and designers). Make sure you avoid commands that do not work with the run-time version (these are documented in the Visual FoxPro Professional Features Guide, under "Distributing Applications").

3. Deploy the OLE Server remotely. You have already created your OLE server. Now, you need to register it remotely. The easiest way to do this is through the Remote Automation Connection Manager (RacMan). RacMan allows you to switch an existing OLE Server, which you already have registered locally, to being registered remotely. In order to do this, make sure your remote machine has that server installed and registered properly and access rights are properly made available to the client. Finally, to create an instance of that server, you must be running DCOM (Distributed COM or Network OLE) between your machines (NT 4.0 or later) or be running the Automation Manager program that ships with Visual FoxPro on the server. See Visual FoxPro documentation for more details on setting up for remote automation and using RacMan.

   Many of the problems associated with using remote automation servers are not with the servers themselves but rather configuring them properly with valid network address, protocol and access rights.

   The biggest concern at this stage is checking for wait states that might stop the client. For example, a MessageBox() call that brings up a dialog box on your server can be closed only when someone manually goes over to the server and closes it. Meanwhile, your application is locked in a busy loop waiting for the server to complete the command.

Strategies