newObjects (fromerly known as ZmeY soft) newObjects IE ScriptBar
Home Products Docs & Libs
pixel.gif (49 bytes)
Products by category
ALP site
ISAPI filters
Forums (discussions)
Buy direct (RegNet)
Articles and samples
Documentation online

Read more ...
Click here
ALP is implemented as an Asynchronous Pluggable Protocol. It acts like a WEB server but without need of network. It executes WEB applications such as ASP pages and CGI applications. ALP makes Internet Explorer to be server and client. With ALP you can write stand-alone desktop applications, CD-ROM autoruns, use ASP for pure desktop software and still keep your code ready to run on WEB servers too.
Write desktop software in ASP and CGI!
download it


Site navigation
ActiveX components

ISAPI Authenticator

Low cost ISAPI custom authentication filter. It ships with a centralized administration tool and a separate tool that enables customers, hosting their site on your server, to manage user accounts for this site only. New version 1.51 is available (02 Jan 2001)

Highlights of the day
Active Label ActiveX
Barcode ActiveX? Much more - the design and printing inside your WEB application
SQLite3 COM ActiveX embeds the SQLite3 database engine and interface to it. Supports paremeterized views and triggers.
Active Local Pages 1.2
Write desktop apps in ASP and CGI. Create wutorun CDs using WEB technologies - yes it is possible!
ActiveX Pack1 family
Desktop Windows, CE/CE.NET and PocketPC! About 50 powerful components for all the Windows platforms.
AXGate 1.1 (new)
Script dafely any ActiveX in Pocket IE. Build applications in HTML and use local resources and components in them.
IE ScriptBar
Create complex toolbars for Microsoft Internet Explorer easier than you may have expected.

Licensing types legend
(M) Single machine license
(U) Unlimited per-company license
(D) Unlimited development license
(S) Special type of licensing

Web development portal

Quick contact

Active visitors
Suggested links
Suggest this page to the other visitors. Click the button below to place this page in the list above .

 newObjects IE ScriptBar   
Price: (D) $99 Discount for resalers ASK
Information Download Buy
How the coding looks?
IE ScriptBar and ALP
Development Template Demo (ZIP 620k)
IEScriptBar with ALP (Zip 1.2 MB)
Download examples
Buy it

IE ScriptBar and ALP

The newObjects IE ScriptBar can be used together with the newObjects Active Local Pages (ALP) to form a powerful suite that makes possible to write browsing companion or other similar applications for Microsoft Internet Explorer. It is quite obvious what can be done that way - the toolbar can provide small UI available to the user at all times, while ALP provides programming environment that enables you to write WEB applications executed into the browser without interaction with remote servers. Thus the browser becomes not only a viewer for online pages and applications but also a combined client and server for locally functioning applications which are written and work the same way the online applications do.

What can be done this way? Almost anything that will fit into the programming model and the user interface specifics. For instance a mail client can be written in ASP - in fact one can port many of the existing ASP WEB mail solutions by just removing a few features not needed or not available in the local ALP environment. Or one can create a link management application that allows the user see his/her links as a portal (again it is possible to port something existing, but in this case it will be good to include some more specific features to make this nice). Other ideas - news collectors, online shopping companions, tools for people working online and many many other applications that will do nicely if implemented as part of the browser that the user can bring up with its full functionality when needed and use it through a minimal user interface (the toolbar) in the rest of the time.

While the ideas for applications are infinite there is a technical details that may be interesting for many developers no matter if they are going to build simple applications or something complicated. Aside of using ALP to drive in-browser running applications it can be used also for some basic IE ScriptBar tasks. 

Using ALP to load the toolbar user interface and the Internet Security (including XP SP2)

By default most of the IE ScriptBar samples and the demo download are configured to load the toolbar UI HTML directly (see the setting (string)Protocol=Direct in the toolbar.cfg). What does this actually mean? The HTML resource designed for toolbar user interface is loaded into the toolbar through the persistence interfaces supported by IE. Thus the WEB browser control shown in the toolbar area is initialized with the UI HTML without performing file load operations on its own. The most important effect is that this way the Local Machine Lockdown is not in effect for the HTML page used as a toolbar user interface. However there is a set back - the toolbar UI is considered part of the Internet Zone (which is the default state for IE). While this is good enough for most of the applications, some of you may want to be able to avoid problems caused by paranoid security settings.

As a WEB developer you know that the user can edit the security settings of the browser and rise them to a level that would not permit anything - even any scripting. If that is the case you will not be able to run any scripts in the toolbar UI HTML. The toolbar script in the background will remain unaffected, but still this is not good enough if you cannot pass the control to it from the toolbar user interface programmatically. 

The solution is simple enough - the toolbar user interface HTML must be considered trusted content - i.e. it must fall into the Trusted Sites zone in order to make it work even if paranoid security settings are in effect (see below how to do this). Again, consider this once more from the user's point of view. In many cases this will not be any problem because an user who has done so is obviously too scared to allow any 3-d party applications to work in his/her browser. Thus the user will not be surprised by the fact that your IE application is blocked by his/her action. However it all depends on what the application does. If it is something that should work even under such circumstances then you must not rely on the IE ScriptBar defaults and using ALP is the best way to do so.

First you need to change the toolbar.cfg
Change the above setting from Direct to ALP (do not forget - to try this you must have them both installed on your machine - separately or you can download the combined IE ScriptBar with ALP package which is already configured this way).

Having this done you will have the toolbar UI HTML loaded through ALP instead of the Direct method. In other words the IE ScriptBar will form an ALP request for the UI page (no need to change the setting - the URL is automatically constructed internally). Besides this allows you to make the HTML page designed for the toolbar area an ASP page. This may give you some other benefits, but we will not discuss this here.

Now you must configure ALP to declare the content correctly so that it would be considered trusted by the browser. Note that by default ALP reports the content it serves "local". In other words by default the ALP served content is treated by the browser as like the content obtained directly from the file system (file: protocol). This is even worse in XP SP2 because it will suffer from the Local Machine Lock Down limitations. So, you need to do something more.

Using the ALP Settings shell extension (bring it up right clicking in the folder containing the toolbar UI and the DLL) edit/create ALP directory settings. There you must set the Security URL to alp:// like this:

In fact ALP Settings dialog will initialize the filed to alp:// if you are just creating the directory settings. This is done so because in more than 50% of the cases the developers are going to this dialog to do this.

Before continuing lets note that you should not mistake the "Declare content safe" option with the "Trusted sites zone" - this option has nothing to do with this!

Now anything served from that directory by ALP is reported to the security manager as belonging to the alp protocol's own domain (all the ALP content belongs to this same domain). This will return the things back on track, but still the content is treated by IE (the alp protocol's domain) as part of the Internet Zone.

Therefore the last thing we need to do is to add settings to the registry that would put all content served through the ALP protocol in the Trusted sites zone. you need to add a value under this key:

HKCU\Software\microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults

Add a DWORD value:


If you want to change the setting for all the users make it to he HKLM (HKEY_LOCAL_MACHINE) instead of the HKCU (HKEY_CURRENT_USER). The number - 2 is the ID of the Trusted sites zone.

How to perform the change depends on when you would want to do it. Most often this is done during the setup, so you can use a section like this in the setup.cfg (if you use ALPInstall):

{ RMAKEALPTRUSTED: (ALPInstBase.InstallRegistry)
    { HKLM\Software\microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults:
    } HKLM\Software\microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults;
    { HKCU\Software\microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults:
    } HKCU\Software\microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults;

The section above does the change in the both registry branches (just in case). In the setup.cfg of the IE ScriptBar with ALP demo downloadable here you will see a bit more extended version of it. There is no need to follow the paranoid manner used in that package, but still if you want to make sure about absolutely everything - this is a good way to do so. The extended settings make sure that the Trusted sites are allowed to run scripts and init ActiveX. Well, it is unlikely that anyone will forbid this for the trusted sites, but as we said the section in the demo show how to set up everything that may get in the way of your application.

Why is this all done this way? Why not simpler?

The answer of these questions concerns both ALP and IE ScriptBar. For ALP it is not a good idea to put factory settings that will put all the content served by it in the Trusted sites. While ALP is mostly used to run applications it can be also used to browse downloaded HTML content much like opening a local HTML file into the browser. So, the user can open a dangerous HTML page saved to the disk from some site through ALP the same way he/she can do this with file protocol (directly opening the page). Therefore the best policy is to keep the ALP putting the content into the Local Machine zone by default (which is the truth after all). Only the content that is especially configured otherwise (see the directory settings above) will be reported as belonging to the ALP domain. This is not a limitation because if one writes an application he/she will surely want to take at least a look at the application level settings and adjust them to fit the application needs. E.g. this policy just protects you from human mistakes done accidentally.

For better isolation it is also recommended to create ALP Application settings and Virtual ALP site in the same directory. While this has nothing to do with the issues discussed here it is recommended for any ALP application (see the ALP documentation and the ALP site for more information)

Download the IE ScriptBar with ALP demo (ZIP 1.2 MB). No documentation is included. The demo just packs them both and does nothing else. You can use it as base for writing combined IE ScriptBar/ALP solutions.

Copyright newObjects (ZmeY soft) 2001-2005