newObjects IE ScriptBar Using the run-time library
 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 by Pack1Creator.CreateObject 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 explicitly yourself.

The run-time library currently includes:

newObjects ActiveX Pack1 core - over 30 objects.

NetStreams -  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 as well.

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.


newObjects Copyright 2001-2006 newObjects [ ]