The anchor Click event is generally the one that triggers heavy-duty action. Regardless of what you do in the event procedure you supply, the browser will react to the click on a link. After your event procedure completes in reaction to a click, the browser will load a linked page in response to an anchor click.

You define the OnClick event procedure in your script with the ID of the anchor, an underscore, and then OnClick. Listing 18.8 shows the OnClick event for the anchored image of the disheveled programmers.

Listing 18.8. The OnClick event procedure for an anchored image.

Sub lnkPicture_OnClick
' This event is called whenever a click occurs on the image.
'   It will link to a different page depending on where the click was.

       ' Show the user where the click was first.
       msgbox "You clicked at X position " & s_Currentx & " & _
            " and Y position " & s_Currenty, 0, "Image Click Feedback"

       ' The link has a target destination supplied in the <A> tag, but change
       '     to the Macmillan Publishing destination if the guide area was_
             clicked on.
       '     Otherwise the default location will be used.
       If InZone(s_CurrentX, s_CurrentY, 205, 199, 253, 250) Then
            location.href = "http://w3.softlookup.com"
       End If
End Sub

When the Click event occurs, a message box is generated to show the x and y position of the click. This makes use of the x and y values that were preserved from the most recent MouseMove on the image. This will always indicate the click position, since the mouse must be at the last place that was dealt with in the MouseMove event. If the mouse had been moved after that event, another MouseMove event would have occurred and caused the global x and y values to be modified again. The most recent values are therefore guaranteed to be current.

Redirecting a Link to Another Location

The last portion of the code in Listing 18.8 illustrates one of the most useful anchor interactions. This is the ability to implement an image map on an anchored image, to process mouse clicks and to redirect subsequent page links right from your code. Most users are accustomed to interacting with large image maps, where they can click on different areas of an image to select a link to another page. This has traditionally required server-side communication, maps, and scripts to derive which region of an image the click was indicating. As the example shows, that ability is now available from within a script. All that's needed to round out the image map model is the means to cause a specified link to take place. And that capability is provided by the location.href property.

The location entity can be thought of as an intrinsic document-level object. No special action is required to define it. The HREF parameter of the object specifies the URL of the link. Assume that you have specified an HREF attribute within <A> tags. When you click on an anchored image, this attribute is the target destination unless, that is, this target destination is overridden by the Click event handler for the anchored image. The Click event takes place after the user clicks on the anchored image but before the browser attempts to load the associated URL indicated in the HREF attribute. Therefore, the event handler is executed during a brief window of time in which the URL can be reassigned before the browser reacts and loads the next page. The event handler can modify the anchors HREF attribute by setting location.href to some other URL.

The sample in Listing 18.8 illustrates this approach. When the Click event occurs, a check is made to see if the click was within the area of the guide that the disheveled programmers are holding. If the click was within this zone, then location.href is reassigned to be http://w3.softlookup.com. The browser will load this page, which is the Macmillan Computer Publishing home page. On the other hand, if the click did not fall within this zone, no assignments are made to location.href. In this case, the HREF attribute is still the same value that was specified in the original HTML for the anchor:

<A id="lnkPicture" HREF="../shared/vbperf.asp">
<IMG SRC="../shared/jpg/picture.jpg" WIDTH=450 HEIGHT=300 BORDER=20></A>

So if the HREF attribute is not overridden by the event-handling procedure, the browser will proceed normally and load the page associated with the anchor. The ../shared/vbperf.asp page would be loaded in response to such a click.

Since you can assign location.href from your code before an anchored link takes place, you have the ability to specify a link dynamically. Your code can make a decision on where to link to after the user clicks on a page. This decision and subsequent redirection can occur without any intervention from the server.

There are many reasons you might want to control a link location from your script. Perhaps you want to direct the link based on values supplied in other fields on a page. For example, assume you have a clothing store page and a user indicates through a radio button choice that he prefers spring fashions. Then you can link him to the spring fashion page rather than the winter fashion page when he clicks on the Sales Info part of an image. Or maybe you author a page for a convention center. Your welcome page provides a general overview of the facility. But if the user clicks on the hypertext link Today's Meetings, you could present different information based on the time of day. If your script detects that it is early morning, you might link to a page of morning activities. And if it detects it is afternoon, you can link to the afternoon page. Of course, you'd want to give all users some way to see all activities, as well, but this could be handled by an additional link.

Another possibility is related to the preload control discussed earlier. You can define an anchor link over an image to go to a subsequent page. The HREF link target for the image is initially specified as a nonexistent location. As soon as the user moves the mouse over that image, the script event procedure can start the preload control's downloading of the relevant file. The script's preload control Complete event can set a global variable to indicate that the preload has finished. When the user clicks on the image, the code Click event handler can check the global variable to see if the required graphic for the next page is fully loaded. If it is, the link can be assigned to location.href and the preload can complete. If it is not, no valid link is provided, and the user receives a message telling him that the next page is not yet ready to be viewed. This may not be a standard technique you'd want to apply to every page. But in certain situations, such as a textguide page with a link that leads to a sample page with a large audio file, this technique could make for a much more pleasant user experience. The user won't be confronted with viewing a page that is not yet able to do anything for him.

Directly Linking to Another Location

So far, the focus has been on redirecting links. But what is actually going on is a little different. When you set location.href, you cause that link to take place and that page to be loaded. It doesn't matter if you do it in response to an anchor click or just in response to a plain old command button click with no relation to an anchor at all. When you tell it to happen, that page will be loaded. Listing 18.9 shows code that loads a page from the Click event of a button.

Listing 18.9. Directly linking to another location.

sub cmdK_Onclick
     location.href = "http://w3.softlookup.com"
end sub

An infinite range of possibilities is opened by this capability. You can cause another page to load in response to anything, from anywhere in your code! Since VBScript gives you access to the events of an anchor and provides an object to direct its link, you have full control over the flow of pages based on the current conditions of a page. As a matter of fact, you can control the progression of pages even outside an anchor. No difficult server code or customized browser is required. Your pages can become as smart and responsive as you care to make them.

Browser Objects

In this guide's first 17 days of learning about what you can do with VBScript, the focus has been on two different layers. One is the core capabilities of the VBScript language. This consists of aspects of the language itself. For example, language keywords such as if and dim are supported directly by the VBScript interpreter. This language will be consistent whether you use VBScript hosted in the Internet Explorer browser, in some other browser, in the Internet server, or even in some application that supports VBScript not related at all to the Web. Then the focus turned looked at objects defined externally to the browser, including ActiveX controls. Objects can be controlled by VBScript because the host environment makes it possible. Support in the Internet Explorer browser and its interface with the VBScript interpreter lays the framework for letting your VBScript access such objects. If you use VBScript in another host environment such as a different browser or a non-Web-related application, it may very well provide the same support. On the other hand, it may not. There is no requirement in the VBScript language definition that dictates that every host must provide this capability.

Clearly, the host environment makes a difference in what you can do with VBScript. There is one more area yet to consider: objects the host itself exposes. You have already seen many such objects today, including the location and document objects. The Internet Explorer, which is the host primarily focused on in this guide, provides VBScript with access to information about itself and with interfaces to control its own behavior through objects such as the document object. These capabilities relate to different ways the browser handles information and provides support for generating and viewing that information. The Internet Explorer provides access to this browser information by making available several intrinsic browser objects. This is not a unique concept. Other browsers such as Netscape Navigator expose a range of objects to JavaScript. For the most part the objects exposed by Microsoft Internet Explorer to JavaScript and VBScript are the same as those exposed to JavaScript by other browsers. This means that intrinsic objects in scripting are likely to be very consistent from browser to browser. However, it is important to realize that the intrinsic objects exposed by the browser are not an inherent part of the VBScript language. If you work with VBScript hosted in other environments, these objects may not be available to you, but if you're in another browser host, odds are they will be.

The real power of VBScript is its ability to integrate objects and easily script together solutions around these building blocks. In that respect, it is very important to realize which objects are available for you to use from the browser. These can become an important part of your scripting arsenal and lead to more powerful pages for your end user.

Objects exposed by the Internet Explore browser consist of the window object, the document object, the element object, the frame object, the history object, the script object, the anchor object, the element object, the form object, and the navigator object. With these objects you can do many things. From your code you can link to other pages. You can detect the version of the browser that is being used. You can respond to mouse movements and clicks on link areas. You can work with the browser history list. You can even find out the name of the referring page for the current page. In other words, you can tell the page that your user visited before he linked to the page that contains your VBScript. You can also use these objects to provide control over multiple frames from your code. The following script statement, for example, could reside in a script in a currently displayed frame page and update the contents of another visible frame:

parent.frames(1).document.writeln "<HTML><BODY><h2> You can " & _
" generate HTML to a page!</h2></BODY></HTML>"
Parent.frames(1).document.close

The possibilities are limitless. A good representative summary of these intrinsic browser objects appears in the sample program Browser.asp on the CD-ROM. This page includes samples of script control between frames and various ways to advance from one page to another and determine information ranging from the browser version to the last date that a page changed. A table of some of the key properties and methods of the browser objects appears on this page. Browser.asp will serve as a good initial reference point to the browser objects for you. A detailed discussion of all the objects would be very lengthy, given the range of capabilities. Refer to Microsoft's documentation for the comprehensive documentation. However, the samples you have seen so far today, as well as the samples you can inspect in Browser.asp, should be enough to get you off to a good start on creating your own sophisticated scripts.

Summary

Today you have examined ways to provide what have been coined "smart pages." These pages use special scripting so that they can preload files for subsequent pages and respond to mouse movements and clicks on anchored images. A script can even select links based on dynamic conditions of the page when an anchored link is selected.

The ActiveX preload control provides the means to preload files. Preloading a file for a subsequent page can take place in the background while a user views a current page. Then, when the user moves to the subsequent page, he will not have to wait for that file to be downloaded from the server. The preload control can start loading a file in advance for a subsequent page as soon as a parent page is loaded. On the other hand, it can be declared through its object definition so that it doesn't start preloading the file until code triggers it. A script can make decisions on whether to preload a file based on the user's other interactions. In cases where a preload occurs, the user will have the perception of better performance. The preload control even provides a complete event so a script can detect when the download of a file is complete and notify the user that the next page is ready.

Another aspect of pages that you can easily control through VBScript is the anchor. The anchor defined through HTML can be specified with an ID attribute. This name is then used in VBScript to refer to events of the anchor. The MouseMove event occurs whenever the mouse moves over the anchored image or text. The MouseMove event is accompanied by parameters that provide the current x,y location of the mouse. These parameters can be used directly or stored for later reference by the Click event. The Click event occurs whenever the anchor is clicked on. The Click event is not provided with any parameter information. Click event code that needs to make decisions based on the current mouse position can do so by looking at the mouse position last stored by the MouseMove event.

One of the important features of the anchor control in VBScript is that you can override an anchor's target link from code. You do this by setting the location.href property. The URL specified in location.href is the page that the browser will load. A script doesn't even have to react to an anchor event to do this. The location.href property can be set from anywhere in the code and will cause the specified link to take place. So you can build your own links anytime, anywhere, for any reason, in your scripts!

All these capabilities add up to provide a very high degree of control over the most important aspects of pages-links, anchors, and associated files. Links let you control the flow of pages. A file is anything an anchor points to, such as an image, an audio file, or a subsequent HTML page. You can load server files, link files, and respond to user interaction with anchors and file links. Smart pages that do more for the user, without any server intervention, are the end result.

Q&A

Workshop

Compare how long it takes a page to load normally with the time required to preload the main graphic file using the ActiveX preload control. Use the preload.asp and nextpage.asp files that are on the CD-ROM that accompanies this guide. The pages generated by these files are shown in Figures 18.1 and 18.2.

Customize this solution to work with your own graphic. These files reference the graphic image. Replace all occurrences of this file reference in both files to reference your graphic image instead. Use the largest file possible to make the preload and no-preload differences stand out.

Instructions for carrying out the comparison of preload and no preload appear on the page displayed by preload.asp. Study the script events from the preload.asp listing in Listing 18.10 before viewing the page. Then, when you view the page, see if you can mentally match up the page feedback to the events you examined.

Listing 18.10. preload.asp source code.

<SCRIPT LANGUAGE="VBS">
<!--
sub cmdPreLoad_OnClick
    lblStatus.caption = "Preload initiated at " & now
    preGif.enable = 1
end sub

sub PreGif_Complete
    lblStatus.caption = lblStatus.caption & "    Preload completed at " & now
    msgbox "Load complete"
end sub

sub PreGif_Error
    msgbox "Error detected"
end sub

sub cmdCheck_OnClick
    msgbox preGif.enable
    preGif.AboutBox
end sub
-->
</SCRIPT>



<!-- ---------------- Preload Control ---------------------------->
<OBJECT
id=preGif
classid="clsID:{16E349E0-702C-11CF-A3A9-00A0C9034920}"
width=1
height=1
>
<PARAM NAME="_extentX" value="1">
<PARAM NAME="_extentY" value="1">
<PARAM NAME="URL" value="http://w3.softlookup.com/super3.gif">
<PARAM NAME="enable" value="0">
</OBJECT>

Quiz

1. Assume that you have an anchor declaration such as the following:
   <A HREF="http://w3.softlookup.com" id=lnkguides>
   <IMG  ALIGN=BOTTOM SRC="../shared/jpg/samsnet.jpg" BORDER=2></A>
   Show the name of the declaration that would be required to handle the Click event for this anchor.
2. Show the anchor declaration that would be required to handle the MouseMove event for this anchor:
   <A HREF="http://w3.softlookup.com" id=lnkguides>
   <IMG ALIGN=BOTTOM SRC="../shared/jpg/samsnet.jpg" BORDER=2></A>
   Be sure to include parameters.
3. Show the statement you would need to add to the Click event in the answer to question 1 to redirect the link. You want the link to proceed to page http://www.microsoft.com/vbscript.