The ScriptBar hosts another IE browser control in itself (Toolbar User Interface). If loaded with appropriately designed HTML it looks just like the rest of the IE toolbars and you can use all the power of DHTML to build whatever user interface you want in it. Is it safe then? Yes the HTML can be loaded only from explicitly specified file or through ALP (if the toolbar is used with it together). It follows the Microsoft's directions about the internet security and works with Windows XP SP2 (and further versions that include the security techniques introduced there). The toolbar's work area can be controlled only by the toolbar script thus even if the toolbar user interface is dynamically reloaded this can be done only by the code implemented in it. 

Still do you need to do everything in DHTML? No - it would be inconvenient at least. The toolbar hosts a plain script file (referred shortly as toolbar script) which runs in the background (invisible) and has access to the toolbar's DHTML view (Toolbar User Interface), the browser main window (with all its frames) and to the utilities provided by the toolbar core component itself. Also the toolbar core (IE ScriptBar Core) is responsible to catch and forward all the events you may want to handle to the toolbar script. Thus it gives you chance to react to the events that occur in the main browser window and the toolbar UI itself. You just implement the event handling routines you need in script and leave out the events you are not interested in. To do so you just need to place a Sub or a Function named after the event name (see the documentation for the list).

The names of the visual areas in the browser are:

As the toolbar user interface (toolbar work area) and the Browser work area are Microsoft Internet Explorer controls the toolbar script controls your own user interface and accesses the pages viewed by the user through two identical objects - only their names are different - the object for the toolbar work area is Toolbar and the object for the browser work area is named Browser. Thus the most complicated work requires you to know only one object's interface an just apply it to two different areas for different purposes. The object is well-known - it is just the Microsoft Internet Explorer's control WebBrowser object. The ScriptBar core DLL creates the toolbar and a mini-browser window in it, initializes it with the specified user interface HTML file (or fetches it through ALP if so specified) and presents it to your toolbar script under the name Toolbar. The same is done with the browser work area. You can see in MSDN (Microsoft Developers Network) for detailed information about the WebBrowser object it and the DHTML object model which is accessible further through it. Lookup the topics about WebBrowser object, IWebBrowser2 interface and DHTML References. 

The above means that if you have DHTML programming skills you already have most of the skills you need!

Still the ScriptBar supports not only scripts. The toolbar script can be replaced by a class written in VB or other COM compliant language. The class does not need to implement anything special - it follows exactly the same pattern as the script. There is only one additional event available for it because in contrast to the script COM classes initialize during their creation and thus they cannot use environment information at that time. So there is an event OnLoad which gives to the object opportunity to initialize its internal members having full access to the Toolbar, Browser, Host and Settings objects supplied by the ScriptBar's core and fetch from them any information needed for its full initialization.

Aside of the Toolbar and Browser objects that represent the visual areas the toolbar script has access to two more objects - Host and Settings. The Settings object is a collection that provides some vital information that allows the script to find out where is it and access its external resources - files, databases and so on. The Host object supplies tools for the script. Among them the CreateObject is most important - it allows the script create objects from the run-time library and also any external COM components it may need. It has some extended features and should be used instead of internal VBScript's CreateObject function or JScript's new ActiveX Object. First of all it will create the objects from the run-time library faster, second it supports dynamic creation of composite objects (A feature of the AXPack1 Family run-time library that allows COM objects to be written in script language and used even without registration in the system registry).

The developers can use any automation enabled COM components in the toolbar script (or class). This means that you can use for instance ADO, FSO, messaging objects, the object hierarchies available from external applications - such as Microsoft Office applications - Word, Outlook, Excel and whatever else you may need. However any developer should carefully estimate the scenario requirements for the developed toolbar. In Intranet/corporative scenarios usage of such objects may be not only convenient - it may allow the developer create an integration point for many software tools used locally which will be always before the employees eyes - in the toolbar in any browser. In other scenarios, such as toolbars created for the public - customers, users interested in services you want to provide online and so on, the case is very different. In such a scenario you have no prior knowledge about what kind of software the users of your product will have on their machines, nor what are the configuration specifics. This moves the focus in another area - maximum compatibility and minimal need of system updates. The perfect solutions would not force the users to install additional software - only your toolbar. So, using the supplied run-time library instead of anything else will be the best way for publicly available toolbars. Lets describe some problems they solve automatically: 

If you have a scripting background in Windows environment you are surely familiar with the FileSystemObject (FSO), the Dictionary object, ADO and so on. You can still use them in the toolbar script. Still, you surely know that this is not as simple as it looks - the FSO is sometimes not available on the user's machine or may be blocked by an antivirus application (well, it is like cutting the leg of your pet in order to prevent it from going out, but you cannot easily convince the users that their antivirus program is not good). ADO may be absent on some older OS-es, an MDB file you use may need update of the system (the MSDAC update) in order to work on older computers. For file access and database functionality you can turn to the toolbar's run-time library and got everything you need from it. In many respects it provides much more functionality than the popular components.

The run-time library which ships with your toolbar is compatible with all the Windows OS-s and needs no outside help to work properly. It is our ActiveX Pack1 Family which consist of the core component AXPac1 core, NetStreams and SQLite COM (note that it expands to cover more areas and by the time you read this page it may contain even more components). All they are already in your package the links mentioned here will just lead you to pages where you can read some online information about them. Their full documentation is included in NDL (download NDL to get the ScriptBar and its run-time library full documentation). The run-time library gives you everything from database, through file access to networking. It may need some learning but the time spent will not be lost, because you can employ it elsewhere without need of license. For example it can be deployed on a WEB server and used in ASP applications, other products contain it and you can install and use it from any other COM enabled product (Windows Scripting Host, VB, MSVC, Delphi etc.). In contrast to the FSO and ADO the AXPack1 Family is available for Windows CE/Pocket PC and provides the same features and the same objects there.

As it was said above - generally the development of this kind of software follows two different design lines when it is built for internal usage and when it is built for the public. While in internal scenarios the aim is convenience and usage of the already available resources, in public scenarios the goal is maximum compatibility and minimal dependencies on external or potentially problem components.

And now, as the tradition dictates, lets illustrate the "hello world" steps. We will use the Sample 1 (you can download it).

It uses a simple HTML file in which you can see how using styles you can design a HTML page that will fit into the Internet Explorer's user interface and will look just like the rest of it - note the color names: buttonface and buttontext for example. Alternatively you can use background images and other typical HTML design tricks to make your toolbar's presence unique if your goal is the reverse - to make it different from the rest of the UI.

The toolbar script in this sample does very little work, it just loads a word list from a text file and searches the WEB pages viewed by the user for them, then displays the found words in the toolbar. No frames are enumerated in the sample in order to keep the code for such a "hello world" level sample minimal.

And here are the files that build it: 

The toolbar script file (in VBScript) - toolbar.vbs in Sample 1

' This code is in VBScript, but it can be written in JScript as well
' This snippet looks for certain words in the 
Const cSFShareDenyNone = &H00000040
Const cReadLineAny = -3

Dim sf, words, file

' Read the words/expressions from the file
Set sf = Host.CreateObject("newObjects.utilctls.SFMain")
Set words = Host.CreateObject("newObjects.utilctls.VarDictionary")
words.allowUnnamedValues = True

Set file = sf.OpenFile(Settings("BasePath") & "words.txt",cSFShareDenyNone)

' The file contans one word/expression per line.
' We load them into a dictionary object and we make them upper case
' to make the search a bit more easier below
Dim line
While Not file.EOS
    line = Trim(file.ReadText(cReadLineAny))
    If line <> "" Then
        words.Add "", UCase(line)
    End If
Wend

' We handle this event which is fired whenever a new page opens in the
' browser work area. And we search that page for the words loaded during 
' the toolbar initialization
Sub OnDocumentComplete(frame,url)
    Dim I
    Dim docContent
    Dim str
    str = ""
    docContent = frame.document.body.innerText
    For I = 1 To words.Count
        If InStr(UCase(docContent),words(I)) > 0 Then
            If str <> "" Then str = str & ", "
            str = str & words(I)
        End If
    Next
    Toolbar.document.all("Found").innerText = str
    Toolbar.document.all("Found").title = url
End Sub

The toolbar user interface HTML - toolbar.htm in Sample 1.

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1251">
<title>Toolbar</title>
<BASE HREF="%BASE%">
<SCRIPT>

</SCRIPT>
<STYLE>
    body { font-family: Arial; font-size: 11px }
    td { font-family: Arial; font-size: 11px }
</STYLE>
</head>
<body bgcolor="buttonface" text="buttontext" topmargin="0" leftmargin="0" SCROLL="NO">
<TABLE WIDTH="100%" HEIGHT="100%">
  <TR>
    <TD VALIGN="Middle" nowrap WIDTH="100%">
        <B><SPAN ID="Found">&nbsp;</SPAN></B>
    </TD>
  </TR>
</TABLE>
</body>
</html>

What else is needed? The file with the words - wrods.txt must be created in the same directory where these files reside and you must review the configuration - toolbar.cfg to ensure that it specifies that these UI and toolbar script files.