Now let's see in a bit more detail how scriptlets are viewed—at least under Win32 platforms such as Windows 95 and Windows NT.
The scriptlet control encapsulates the HTML rendering engine of Internet Explorer 4.0 and uses it to load and run the scriptlet's page normally. This viewer is in the
and corresponds to the COM server whose identifier is CLSID_HTMLDocument. Once completely loaded, the scriptlet's page exposes its own DHTML object model and gets displayed.msHtml.dll
From now on, the scriptlet component can interact with its container (for instance, Internet Explorer 4.0).
The outer box in the above diagram renders the scriptlet's site inside a host Web page.
The scriptlet's DHTML object model, however, is available only to the script code that actually forms the scriptlet itself. Unless you export objects explicitly, the container won't ever be able to access the hierarchy, since the scriptlet Component hides it. Though we have previously demonstrated how a scriptlet can export its own
object.document
The script code built into the scriptlet defines its public interface, which is exposed to the host environment through a WebBridge object.
This bridge layer works as a broker. It interprets the external calls and passes them up to the scriptlet. The opposite occurs for the events fired by the scriptlet and notified out of it.
The WebBridge layer is always the same, whichever scriptlet it governs. It also negotiates with the container about the scriptlet's site and implements some general properties and methods inherent to the site's style and functionality. For instance, whether the site should display scrollbars or a context menu, or whether it should make its content selectable via drag-and-drop. These stock attributes are exposed to the scriptlet, but their actual implementation requires a negotiation with the container.
Oversimplifying, we could say that inserting a scriptlet into an HTML page forces you to embed another WebBrowser's instance. This is untrue. What's really embedded is an instance of the IE 4.0 viewer engine and, therefore, just a part of the WebBrowser component. Around it, the WebBridge layer takes care of hiding most of the details, presenting the page (that is, the scriptlet) as a real object component. Don't forget that while an ActiveX component is able to converse directly with its container, scriptlets are not. scriptlets still need an intermediate layer that will host them and forward requests in and out.
Now let's take a look at the windows involved in such operations. The next figure shows the pile of windows created when Internet Explorer 4.0 is hosting a Web page—and a scriptlet is a Web page.
We can observe a "Shell DocObject View" window, which includes an "Internet Explorer_Server" window. Both windows occupy the entire client area of IE 4.0. The drawing occurs inside the inner window. In fact, if the page hosts some windowed ActiveX controls, these windows would all be children of the server window of class "Internet Explorer_Server".
Let's see what happens when IE 4.0 views a Web page with a scriptlet.
As you can see, there are two windows of the same "Internet Explorer_Server" class. The outer refers to the whole client area of the browser. The inner refers to the scriptlet. This demonstrates that the rendering engine of IE 4.0 is duplicated when the browser opens a page which contains a scriptlet.