Wintertree Spelling Server

Home Site index Contact us Catalog Shopping Cart Products Support Search

You are here: Home > Support > Wintertree Spelling Server > Pop-up window mechanism in ASP Example 4 and ASP.NET Example 3

Explanation of the pop-up window mechanism in ASP Example 4 and ASP.NET Example 3

This document describes how the pop-up window mechanism operates in ASP Example 4 and ASP.NET Example 3. These examples use a pop-up JavaScript form to interact with the user during the spelling-check process. The user interacts with the form displayed in a pop-up window to dispose of spelling errors. The form is independent of the application's form (i.e., the form containing the text areas being spell-checked).

Usually, the results of form submission or post-back are displayed in the same browser window as the original form. The window to which submission results are displayed is known as the "target," and by default, the target is "_self", which means the original window. In ASP Example 4 and ASP.NET Example 3, however, we want the results returned when the form is spell-checked to be displayed in a different window. Otherwise, the original form would be obliterated by the spelling form. This can be accomplished using a little client-side JavaScript code.

ASP Example 4 and ASP.NET Example 3 contains two submit-type buttons, one labelled Submit and the other Check Spelling. In your application, the Submit button is the one that causes the form to be submitted (posted back) to your application's server-side script. The Check Spelling button causes the form to be submitted (posted back) to a server-side script that checks the spelling of specified text areas in the form.

The Submit and Check Spelling buttons are each linked to JavaScript functions via the ONCLICK attribute. In ASP, this is accomplished using the following HTML tags:

<INPUT TYPE=BUTTON NAME="Submit" VALUE="Submit" onClick="onSubmitBtn(0)">
<INPUT TYPE=BUTTON NAME="CheckSpelling" VALUE="Check Spelling" onClick="onCheckSpellingBtn(0)">

In ASP.NET, the buttons are linked to the JavaScript functions at runtime using code similar to the following:

SubmitBtn.Attributes.Add("onclick", "onSubmitBtn(0);")
CheckSpellingBtn.Attributes.Add("onclick", "onCheckSpellingBtn(0);")

The Submit button is linked to a JavaScript function named onSubmitBtn, and the Check Spelling button is linked to onCheckSpellingBtn. When the Submit button is pressed by the user, the onSubmitBtn function is invoked. When the Check Spelling button is pressed, the onCheckSpellingBtn function is invoked. The onSubmitBtn and onCheckSpellingBtn functions are located in a file named SubmissionScript.js. These functions are run on the client system by the browser.

The ONCLICK attribute allows us to invoke some JavaScript code before the form is actually submitted. Usually, submit-type buttons in a form do not have a specific ONCLICK attribute. We define an ONCLICK attribute for the buttons because we want to control which window the results of submitting the form are displayed in. If the Check Spelling button is pressed, we want to display the results of form submission in a separate pop-up window. However, if the Submit button is pressed, we want to display the submission results in the browser window containing the form (which is the usual, default behavior).

The onCheckSpellingBtn function (which you'll recall is linked to the Check Spelling button) creates a new browser window named "spellwin" and sets the form's TARGET attribute to "spellwin". This causes the results of submitting the form to be displayed in the "spellwin" window. The spelling checker script on the server checks the spelling of specified text areas in the form and generates a new form containing buttons and other controls that allow the user to dispose of any misspelled words found. Once the form's TARGET attribute has been modified, it will remain that way until it is modified again. As it happens, the TARGET attribute will also be modified by the onSubmitBtn function (which is linked to the Submit button), which sets the TARGET attribute to "_self" so the results of form submission will be displayed in the form's original window. Here's a synopsis of what happens when the Check Spelling button is pressed:

Check Spelling button is pressed
onCheckSpellingBtn function is run
New browser window named "spellwin" is opened
Form's TARGET attribute is set to "spellwin"
Form is submitted

The following happens when the Submit button is pressed:

Submit button is pressed
onSubmitBtn function is run
Form's TARGET attribute is set to "_self"
Form is submitted

What if you add another submit-type (or post-back) button to your form? If you do not change the form's TARGET attribute, pressing the new button will cause the results of submission or post-back to be displayed in the default, original browser window (_self) or in the "spellwin" window if that happens to be the last one used. For example, if the user clicks the Check Spelling button, then clicks your new button, the results of form submission will be displayed in the "spellwin" window, which is probably not what you want. Why does this happen? Pressing the Check Spelling button changes the form's TARGET attribute to "spellwin" and the TARGET attribute remains that way until it is set again. The solution is to link your new submit-type button to the onSubmitBtn function so the TARGET attribute will be set to default.asp before the form is submitted. In ASP:

<INPUT TYPE=BUTTON NAME="NewSubmit" VALUE="New Submit" onClick="onSubmitBtn(0)">

In ASP.NET:

NewSubmitBtn.Attributes.Add("onclick", "onSubmitBtn(0);")

(Of course, you would probably give your button a more descriptive label than "New Submit.") Now, when the New Submit button is clicked, the onSubmitBtn function will set the form's TARGET attribute to "_self" so the results of form submission will be displayed in the original browser window. If you had several submit-type buttons, all would need to be linked to the onSubmitBtn function.