You are absolutely right! We will make sure to fix this in the next update. On the meantime, you will need to delete the registry entry using other means. There are two options:
1. Use the registry editor (regedit.exe), to delete the ErrHandler entry in hkey_local_machine\software\Aegis Group\FoxWeb\CurrentVersion.
2. Create a FoxWeb script which contains the following command:
This command will remove the value you set in the Control Center.
Sent by Shayne Sharpe on 01/21/2004 10:00:45 PM:
Once I've applied an error template script on the config page, how do I go about removing it to set it back to the default?
The field does not allow me to delete contents.
Sent by FoxWeb Support on 01/12/2004 12:11:29 PM:
The error template is called by the default FoxWeb error handler. If you override this handler with your own ON ERROR command, then the error template will not be used.
Sent by Shayne Sharpe on 01/11/2004 10:11:21 PM:
If our scripts store the default handler, performs an action and then restores it; would/should the FoxWeb error handler call the script specified in the Error Template? Initial tests show that it doesn't.
Sent by FoxWeb Support on 01/08/2004 11:17:24 PM:
FoxWeb has its own error handler that is called via the ON ERROR command. This error handler logs errors and then either returns default content to the browser, or calls the script specified in the Error Template field of the FoxWeb Control Center.
If you issue an ON ERROR command in your scripts, then the FoxWeb error handler never gets called, which will also prevent the error template from being called. We discourage this practice, because it may cause channel stability issues. The FoxWeb error handler has been refined over the years to handle errors gracefully and make sure that channels recover and immediately become available to serve subsequent requests. Using a different error handler may jeopardize this.
Sent by Shayne Sharpe on 01/08/2004 05:22:20 PM:
We currently have an PRG set as an error handler under the Foxweb 2.5 configuration using 'Error Template'. Was wondering whether this will trap the error again even though it had previously been trapped and handled by a lower level PRG using the 'on error' command?
(part of an upgrade test from 1.25)