newObjects IE ScriptBar newObjects IE ScriptBar
 

On the picture above you can see a snapshot of Microsoft Internet Explorer (IE). The "My Links" toolbar is created and handled by newObjects IE ScriptBar control. As it looks like the rest of the IE toolbars it is in fact much simpler for the developers to put whatever they want there and create complex IE toolbar plug-ins by using HTML, some images and VBScript or/and JScript only. No need to write in C++, no need to deal with cumbersome Win32 API-s and at last but not least one needs very little aside of script language and HTML knowledge in order to build fully functional IE toolbar product.

How it works?

The toolbar hosts another IE browser control in itself. 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. From version 1.1 you can also use dynamic menu structures and show pop-up menus in response to user actions. The menus are defined at run-time over a simple but flexible object architecture that allows you compose the menus dynamically - as the current state of your application dictates. Of course, having dynamic architecture means that you can also use static manus (menu structure that doesn't change during the application life time) - you can just put simple menu definition code or devise something more functional by implementing a routine that reads the menu structure from a file.  

Is it safe to use IE this way? Yes the HTML can be loaded only from explicitly specified file or through ALP (if the toolbar ships together with it). 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 by the code implemented in it only. See also IE Zones and Security techniques.  

Still do you need to do everything in a script written in the toolbar's DHTML design? No - on contrary it would be inconvenient at best. The toolbar hosts a plain script file (referred in this documentation as toolbar script) which runs in the background (invisible) and has access to the toolbar's DHTML view, the browser main window (with all its frames) and to the utilities provided by the toolbar core component itself. Also the toolbar is responsible to catch and forward to that script all the events you may want to handle. Thus it gives you chance to react to the events that happen in the main browser window and the toolbar UI itself. You just implement the event handling routines you need in script and leave the events you are not interested in un-handled.

The newObjects IE ScriptBar ships with AXPack1 family which gives you a rich set of components through which your toolbar code can do almost everything not urging you to look for 3-d party components unless they are especially related to a very specific functionality (for example you do not need 3-d party components to read/write files or implement database functionality, but if you want to integrate with Microsoft Outlook you would need to use its object model, of course).

The names of the visible elements are shown on the image below:

Requirements

The newObjects IE ScriptBar runs on each IE version that supports toolbars which means IE 5.0 or later and on Windows 95/NT4/98/Me/2k/XP/2k3 and later with the appropriate IE version installed. Almost all the Windows computers today have IE version 5.0 or more recent pre-installed. In fact you can assume that your toolbar will work on IE 6, IE 7 or later version and only occasionally on older IE version.

How is it licensed?

The newObjects IE ScriptBar is licensed per-application. You need one license for each different IE toolbar application you want to build. There is no limitation on the number of clients to which you will distribute the product you build - the redistribution is royalty free which means you pay for license once with no hidden further charges.

The license has also technical impact. You receive a copy especially built for you with your own ClassID, registry name and ProgID. This gives to your toolbar application unique identification and it will not interfere or be replaced by any other toolbar applications from other vendors based on the ScriptBar product. If you violate the license and distribute two different toolbar applications with the same license and binaries for it - they will replace each other when installed on an user machine - i.e. the last installed will remain active while the previous will no longer load.

 

 

Creating a toolbar step-by-step.

Reference information

How to re-distribute?

Once you build your toolbar and obtained a license for it you are almost ready to go. When purchasing a license you receive an installer package based on ALPInstall. It contains your DLL and the run-time DLL-s, a dummy toolbar application to indicate where you should put yours and is pre-configured with some sample names for the installer. After replacing the dummy application you can just edit the setup.cfg file to set appropriate values to the human readable entries and inspect the rest. Then you must review your work and see if you are using additional external components and include them in the setup package as well (if any are used). Then you are ready to test the setup to see if everything is configured ok, package it with ZIP, RAR or another archiving utility and put it for download on your site or send it in some other manner to your users.

You may want to do some additional things. For example you may want to sign the DLL with a digital certificate. In such case you must buy one and sign the toolbar's DLL and possibly the redistribution archive or SFX. This will tell the users who is the vendor of the application. While this is not crucial it will calm down the users that are highly concerned about the security.

Active download? It is possible of course, but concerning the latest developments we do not recommend it. If it is very important for you see the Microsoft Development Network for information about this IE feature. You can contact us for assistance. But again we do not recommend that way as it became too hard lately - the user security settings may be too high thus not even prompting for permission to install. In any case you should have a traditional installer download at least as a backup installation method.

When packing a download or some other kind of redistribution package - what archiving utility to use? We recommend WinRAR for it gives best compression and supports creation of self extracting executables (SFX) which can be configured to unpack in a temporary folder and run the installation. You can use also one of the ZIP clones for Windows, just make sure that the utility supports all the features you will need (SFX, install invocation, unpack to temp folder, keeping the internal directory hierarchy of the archive).

Using other setup/installation building tools. You can use other setup solutions such as InstallShield or Wise for Windows and so on. For example if the toolbar application you are building is a part of bigger product for which you already have something prepared you may want to include the toolbar files with the rest. To do that you must get from the install package you received the following files and include them in your install package:

Utility DLL:
newobjectspack1.dll, NETStreams.dll, SQLITECOMUTF8.dll
Configure your setup package to install them in:
%SYSDRIVE%\Program files\Common files\newObjects\ActiveX

The toolbar DLL:
newObjectsIEScriptBar.DLL (you can rename it as preferred).
Configure your setup to install it in a directory of your choice. For example:
%SYSDRIVE%\Program files\YourCompany\ApplicationName

All the other files you have built or edited:
toolbar.cfg, the toolbar script, the user interface HTML, its resources (images for instance), any additional files such as databases, text files and so on.
Configure your setup to put them in the same directory as the toolbar DLL above.

All the mentioned DLL-s are self-registering COM DLL-s and must be registered with the system. If your setup creation solution supports marking of individual files as shared DLL-s mark all the utility DLL-s as shared (they are often used by other products from various vendors too). If you cannot see such an option then perhaps your setup marks each DLL as shared - it is recommended to check the setup documentation for this. Note that this is also important for any DLL that may happen to be used by other application. I.e. it is good to check this for all the DLL-s in your product's setup - even those related to other parts not part of the toolbar. An exception can be made only for DLL-s for which you are absolutely sure no other product will ever use them. In this case this is the toolbar DLL only - it can be used in a single product only, if you have more than one toolbar application you will have separate DLL for each of them. What will happen if you fail to do this? The other applications that use the DLL you forgot to mark as shared my uninstall it if the user uninstalls them and this may render your application un-functional in an unpredictable future moment. The setup solution in the package sent to you with the license has the DLL-s already marked as shared in its configuration.

 

newObjects Copyright 2001-2006 newObjects [ ]