There are different methods that can be used to debug FoxWeb programs and most of them are no different than the ones used in conventional FoxPro programming. These methods range from interpretation of error messages to full scale tracing through the program. You should decide according to the elusiveness of the error which method to use.
Here is a list of the various debugging techniques:
If you are unsure whether a browser sends the correct values for fields in HTML forms you can change the action of those forms so that they point to the internal FoxWeb script show_cgi. This script returns all the information sent by the browser as part of the request, as well as general system information. Although show_cgi does not exist as a separate script file, it can be called just like you would call any other FoxWeb script:
Another way to utilize show_cgi is to call it within your scripts:
Whenever an error occurs in a user program FoxWeb returns to the browser a description of the error that includes the error message, the program in which the error occurred and the line number of the line that caused the error. In most cases this information is enough to help you identify and correct the error.
In addition to sending an error message to the browser, whenever an error occurs FoxWeb inserts an entry in the error log. The error log contains a wealth of information pertaining to the error, including the name of the program, the name of the calling program, the error number and message, all Server Variables, any existing form fields, the active memory variables at the time of the error, and all open databases and tables. The easiest way to examine the error log is to use the Error Log Viewer.
Status messages strategically placed in your code can indicate progress through the program, as well as display the results of expressions including contents of memory variables and fields. Your messages can include the FoxPro function LINENO() to indicate their position in the program. You can also use the SECONDS() function to determine how long it takes to execute various sections of your code, and thus find bottlenecks in your scripts.
The following example displays messages after each of the two SELECT statements, indicating how long they take to execute:
Just as with any FoxPro program the Trace window can be used to step through the code of FoxWeb programs. The suggested method of tracing is to place the line SET STEP ON at the beginning of the code block to be stepped through. This command suspends program execution and activates the Trace window. It also enables the Command window, so users can issue FoxPro commands. Depending on the Script Timeout setting the browser might get a "Could not get Response from Data Server" error.
Obviously, the VFP debugger does not recognize FWX scripts. In order to trace through your FWX code you must enable the Keep PRG Files option in the FoxWeb Control Center, and delete the existing FXP file so that FoxWeb will be forced to recompile the script. This will enable you to trace through the PRG file, which is generated from your FWX script.
Important: After stepping through the desired code segment you must click on the "Resume!" option in the Trace window to complete execution of the request and reset the FoxWeb channel. Before doing this, it is a good idea to disable tracing between breaks.
In order to be able to trace through scripts you must first set the following options in the FoxWeb Control Center:
|Use Run-Time DLL:||Disabled|
|Run as Service:||Disabled|
|Keep PRG Files:||Enabled|
If you make any changes to the above settings you will need to re-start FoxWeb in order for them to take effect. Remember to revert to the original configuration once you are done debugging your scripts.
For more information about using the Trace window and stepping through FoxPro programs check the FoxPro documentation.