Recommended: Use ASP to build a private search engine Many Internet enthusiasts rack their brains to make the functions of their website more comprehensive when creating their own personal homepage. Here, the author introduces a method to use ASP to build your own search engine. Basic idea is to use forms to store search keywords submitted by users in variables.
7.5.1 General debugging technologyIn Chapter 2, you have seen how to use the Response.Write method and the Request collection to display the contents of the collection. If the code wants to use the value from the request, the first thing to do is to ensure that the required value exists. The easy problem is that the HTML control name in the <FORM> webpage is misspelled or changed, or the wrong client appears when creating a query string attached to the URL.
1. Display various collection contents
When the program tries to run with the user-provided value, it may not get the desired result, or nothing is obtained. Remember, using Request.Form(ThisControl) does not cause an error when you reference a value that does not exist in a collection of Request objects (for example, if you do not have a control named ThisControl on the form. The result may only get an empty string. This may also happen if you expect to find a value stored in the user's Session object or global Application object variable.
If you create a page to display the contents of all Request object collections, Session and Application objects' Contents and StaticContens collections, you can access them using Server.Execute. The work needs to be done is to add the following program line to the ASP web page to display the entire content of the collection. Of course, according to the location where the file is stored on the server, the corresponding path must be set for the file.
<% Server.Execute /path_to_file/debug_Request.asp %>
This is a great way to ensure that any value we want to find in the Request, Session, and Application collections do exist and contain the appropriate value. A corresponding file is provided in the sample file Chapter07 subdirectory of this book, named debug_Request.asp. It is basically a combination of the show_request.asp web page for Chapter 2 and the show_application.asp and show_session.asp web pages for Chapter 3, but removes some HTML program code. It simply iterates over the collection and puts the values into the current page.
This page can be viewed by running the Custom Error Page instance. This example was seen earlier in this chapter. When opening it, please select the Display debugging information check box, or open it directly in the main menu web page in the chapter07 directory.
2. Show intermediate values
The second way to view the running situation in a web page is to display the value of the variable when the web page runs. This traditional technology cannot be discarded when you roughly know where the error comes from and which variable is working. However, due to the changes in the IIS 5.0 web buffering method, it is difficult to use this technology.
In previous versions of ASP and IIS, page buffering was turned off by default, and almost no one thought of turning on the buffer (open with Response.Buffer = True), unless they wanted to use Response.Redirect to complete the redirection of the webpage (see Chapter 2). When responding to multiple requests, the buffering reduces the number of switching between web pages, thereby improving the efficiency of IIS.
However, when a run-time error occurs that stops the run, IIS automatically calls the Response.Clear method and then calls Server.Execute to load the custom error page, so any output written into the web page is lost. The solution is to temporarily add the following program line:
<% Response.Buffer = False %>
This program line is placed at the top of the page after the <@LANGUAGE...> directive, and any debug output generated by the Response.Write statement will appear at the top of the custom error page. Remember to remove it after you finish debugging the web page.
This method is sometimes useful to force the program to run through an error point and then display suspicious variable values. Simply add the On Error Resume Next statement near the beginning of the web page, and then you can access the Err object (in VBScript) and display the error number, error source, and description.
3. Check component attribute values
If the component used has properties set in the ASP script code, after the setup is completed, and before and after the component method is called, the error can be tracked by displaying all properties (or just suspicious properties). When a method is run, it may be found that the property value has been accidentally changed by the component, perhaps intentional, or because of a defect in the component. Don't make any assumptions without checking the actual code yourself.
7.5.2 Microsoft Script Debugger
When developing more complex applications that handle real tasks, a more powerful tool is often needed for debugging. Microsoft Script Debugger is a debugging tool that allows debugging scripts running on clients and servers. It can be used for any ActiveX-enabled scripting language (including VBScript and JScript), and can also be used to debug calls to Java applets, Java Beans, and ActiveX components.
Before studying this tool, briefly explain some issues. As mentioned earlier, an ASP application consists of two types of scripts, one is a client script and the other is a server script. Client scripts are usually composed of VBScript or JScript script statements that appear in the HTML page when they arrive at the client and are executed there, possibly when the document is loaded or in response to some events. Server-side scripts are usually also composed of VBScript or JScript statements. When the browser asks for a web page, the server-side script is executed by IIS. In the following discussion, the method of server-side script debugging will be discussed. However, many of the techniques discussed can also be used for client script debugging.
1. Server-side debugging
To debug server-side scripts, run the script debugger on a computer running IIS, however, debugging must be enabled before using the script debugger. To optimize performance, ASP-based applications turn off debugging by default.
Be careful not to turn on debugging on productive applications (i.e., public websites that are active and used by others). This will slow down the entire application and errors can cause the web page to stop running indeterminately.
Debugging can only be set for virtual applications and the entire web site. To enable debugging, open the Properties dialog box of the application or site, in the Home Directory tab, click the Configuration button, in the App Debugging tab of the Application Configuration dialog box, select Enable ASP server-side script debugger, and prepare to debug our application below.
Note The Application Configuration dialog box contains a check box that enables client script debugging. This is not implemented in IIS 5.0 and is only marked as reserved for future use in the documentation. If the usual 500-100.asp custom error page is not available, the Script Error messages section contains the text.
(1) Processing server scripts
Unlike client scripts, ASP-based application scripts are not event-driven. When the client asks for a web page from the server, the server reads the web page content and processes all server scripts (i.e. everything in the <%...%> and <SCRIPT RUNAT=SERVER></SCRIPT> segments), as well as inline script segment content in HTML text, such as:
The valve of the result is: <% = strResult %>
Process flow display box diagram
When IIS loads a web page, all scripts in the ASP page will be processed. Before any output is sent to the client, the ASP and script engine can catch syntax and runtime errors (unless you turn off the buffering or call the Response.Flush method).
(2) Help provided by the script debugger
When enabling script debugging, if an error occurs, you can see a dialog box describing the error of ASP code on the server screen. Click OK, and then call in a read-only copy of the current ASP web page. The script debugger is opened. The line that appears in the error is indicated by the arrow.
Here, the error occurs because of the name error of the Page Counter object method, which should be PageHit instead of DoPageHit. At the same time, the script debugger found an error and terminated the page's running. The buttons on the toolbar are used to continue the program, single-step program running, or terminate the page's running.
The button on the far right of the toolbar opens the Immediate window in the script debugger, which can be used to interact with the page, and it is very likely to find a place where the error occurs. For example, variable values or component properties can be queried or set, internal functions and subroutines, custom functions and subroutines, and object methods that have been created, etc. can be executed. In the figure, the PageHit method of the Page Counter component is called, and the Hits property is then queryed to get the value at that point in the running script.
To understand why script debuggers should not be used on public websites, you can open a page containing server-side errors from the client. In this case, the error message dialog appears on the server and the script debugger is also opened on the server. On the client, the page is not loaded until the script debugger running on the server is closed.
(3) Start and use the debugger
After enabling script debugging, the script debugger will automatically occur when an error occurs in the web page of the virtual application.
Share: ASP Example: Production of Word Cooperation Games This is a game about word coding, written in ASP, VBScript and JavaScript. No major problems were found under test under Win98 OEM2, PWS, and IE5. Usage method: Method 1: For example, the directory of your 3W service is C:Inetpubwwwroot.