The newObjects IE ScriptBar uses our newObjects
ActiveX Pack1 family as run-time library. This means that it
ships with several COM DLL modules that implement over 40
objects. To use them you simply need to create the object you
need and call methods or set/get properties on it.
How to create the objects?
In the toolbar script
you should use the Host.CreateObject
method. For example:
Set sf = Host.CreateObject("newObjects.utilctls.SFMain")
Although the script language supplied CreateObject in
VBScript and new ActiveXObjects in JScript would work we
recommend you use the Host.CreateObject in the toolbar script.
This will protect your work from potential changes in the
security model of the OS. Also Host.CreateObject supports
extended features such as creating composite objects written in
script from a file (i.e. COM objects that are not registered
with the system), some aliases and so on. The Host.CreateObject
is implemented by the ScriptBar over the implementation supplied
method. In fact Host.CreateObject acts like Pack1Creator.CreateObject
called with flags parameter set to 0.
All the objects in the libraries listed below are part of the
run-time library and thus they are part of the demo packages and
the packages received when a license is bought. Therefore there
is no need to be worried for their availability - they are
always with your application unless you have deleted them
The run-time library currently includes:
Pack1 core - over 30 objects.
- 6 objects that implement TCP/IP and IRDA communications.
They perform the lookup and connection tasks and a SFStream
object from the AXPack1 core is used to drive the data transfer
as like the network connection is a file.
SQLite COM -
Single object that implements zero-configuration SQL database
engine and interface to it. It uses collection/dictionary
objects from the AXPack1 core when returns query results.
You may need additional samples for some of the objects.
Download the AXPack1 family package which contains samples
written for WSH, ALP/ASP and other environments. The techniques
illustrated in these samples can be used in the toolbar script
One of the toolbar samples you can download from our site
(sample 2) use the COMScriptThread object (from AXPack1 core
DLL). This technique is extremely useful if your toolbar will
perform complex and time consuming tasks. Using threads you will
leave most of the work in the background and the user will not
feel any inconveniences when your application performs it. If
you implement such tasks in the toolbar script itself it will
work in the same thread in which works the IE user interface and
the user may get the browser stuck for a few moments if the
tasks performed require more time. We recommend you try this
technique on your own, do some experiments if you need and
employ threads for the tasks that may take more than half a
second on slower machines. Essentially any network oriented task
(such as fetching/sending data to remote servers, searches and
so on) should be considered slow, because you have no guarantee
that the remote party will respond quickly. Do not get misled by
the performance shown on a local network - through VPN or any
remote connection the same task may slow down to several seconds
and even minutes. Therefore you should employ threads or use
non-blocking sockets (which is harder than using a thread)
whenever it is possible.
Using other components
Through the same method - Host.CreateObject you can create
any registered COM object. If you are going to use 3-d party COM
objects you must include them in the re-distribution package of
your application. Before resorting to such an object check the
toolbar's run-time library and see if you can do your work with
it instead of using other components. The effort to learn a new
object will pay back by simplifying the redistribution of your
application. Note that AXPack1 family is compatible with Windows
95/NT and later while some of the 3-d party objects may not be
compatible with some of the earlier Windows versions. Thus the
convenience - to use something you already know may become a
problem or even cause failure of your project if it happens that
some users have troubles caused by such a component. Before
deciding what to do - check any 3-d party object you have in
mind for its compatibility range and ensure it will work
flawlessly on each prospective user machine.