While developing this DHTML X-Ray utility, we have come across a number of interesting features and shortcomings. In particular, there are a couple of them we'd like to examine a bit more thoroughly. The first one refers to the onscriptletevent event.
Suppose you write an HTML page that hosts a Scriptlet and detects and handles its custom events. For example, you could consider the following event.htm page.
<html>
<head>
<title>A Demo Page</title>
</head>
<body>
<script language="VBscript" for="window" event="onload">
Toolbar1.AddItem "Back", "Prev_N.bmp", "Prev_H.bmp", "Prev_D.bmp", "Prev_G.bmp"
Toolbar1.AddItem "Forward", "Next_N.bmp", "Next_H.bmp", "Next_D.bmp", "Next_G.bmp"
Toolbar1.AddItem "Play", "Play_N.bmp", "Play_H.bmp", "Play_D.bmp", "Play_G.bmp"
Toolbar1.AddItem "Stop", "Stop_N.bmp", "Stop_H.bmp", "Stop_D.bmp", "Stop_G.bmp"
Toolbar1.Cursor = "hand"
Toolbar1.SetButtons
</script>
<script language="VBscript" for="Toolbar1" event="onscriptletevent(n,o)">
if n="OnItemClick" Then
MsgBox "Clicked item " + o
end if
</script>
<object id="Toolbar1" data="Toolbar.htm" align="baseline" border="0"
width="300" height="60" type="text/x-scriptlet">
</object>
</body>
</html>
The page includes the toolbar Scriptlet we saw in the previous chapter. If you run the page from within Internet Explorer 4.0, and click the toolbar's buttons, you get a message box informing you of the ordinal number of the button clicked. However, if you run the page from within a Visual Basic utility that uses the WebBrowser control, you won't be able to catch any of the onscriptletevent events. To get those notifications, you must resort to the Scriptlet Control. However, hosting Scriptlet-based documents in a WebBrowser control doesn't seem to provide the same functionality as the whole Internet Explorer 4.0.
There are Scriptlets that have an empty body that is filled out at run-time only. So if you scan the Scriptlet page, as you see it in a browser, you often won't get much. To understand what we mean, try displaying the well-known toolbar.htm file through Internet Explorer 4.0, and observe what results. Then, display a page that scripts the component (like the one listed above) and—again—see what happens. According to the content of the script instructions, the toolbar will show some images. How can you get the name of these files? If you want to know all the files that compose a given page, then you can't discard them—even if they are not explicitly part of the Scriptlet.
But there's a subtler circumstance. A Scriptlet like the expandable text component discussed above, and presented in Chapter 9, includes two bitmaps: one for the collapsed state and one for the expanded. Only one (or even none) of them is explicitly defined in the body. Consequently, only one of them is caught by scanning routines. Nevertheless, both are undoubtedly part of the Scriptlet.
How to get at them? This is a problem quite similar to statically identifying the DLLs a Windows program can load dynamically.
Well, there isn't a global, definitive, and totally reliable solution. Something is possible if the component exposes its own document object. In this way, we could try to work around the problem by analyzing that document object—which renders the state of the Scriptlet as modified by the script code of the host page.
The object identified by
Set obj = doc.All.tags("OBJECT")
s = obj.Item(i).document
is not the document object of the i.th object, but the host page's document object.