This DLL contains variety of ActiveX components packed all in one DLL. They cover different applications such as file/stream access and management, script hosting and execution, collection tools, configuration and registry access, structured access to binary files (as set of records) and so on. The list below contains links to the documentation of each object.
The DLL can be registered manually using the regsvr32 utility (type: regsvr32 newobjectspack1.DLL on the command line in the directory containing the dll). Also all the objects in the DLL load their type information directly from their resources thus they could be used without prior registration with tools that support on-the-fly ActiveX usage - such as ALPFrame (part of the ALP product). This means all the components are applicable for usage in CD-ROM autorun applications.
The DLL itself is freeware and can be redistributed with any product without need of additional acknowledgement. Support for the objects in the DLL is provided to the customers of our products and services. Questions from other users will be answered too, but with lower priority.
Documented DLL version: 2.0.0.8
List of the objects implemented in the DLL:
Script hosting and execution
ScriptManager2 - Allows execution of any Active Script, usage of the script as an object (e.g. loading it and calling the routines defined in the script as object members), event handling.
ScpAggregate - Uses the ScriptManager2 to implement a compound scripting "aggregate" that may host scripts written in different Active Script languages and presents it the the application as single script. E.g. parts written in VBScript and parts written in JScript (JavaScript) could be loaded and then treated as like they are one single script. (documentation not finished)
Storages and Files. Components for file management, access to files, streams, OLE compound files, binary files random acces and so on.
SFMain - A bit similar to the FSO (FileSystemObject from the scripts runtime library). It provides access to the file system - files, directories, drives, OLE files, memory streams and some other machine resources. In difference to the FSO this object together with the other "Storages and Files" (SF) objects exposes better abstraction and thus allows much wider range of resources to be accessed through simple and common programming interface. While FSO provides access to only text files in the file system, SFMain provides text, binary and structured access to any file or stream-like resource (such as memory streams, OLE files etc.) and not just files.
SFStream - Implements the stream abstract object. This is used for file and stream access. When a method of SFMain opens /creates a file or another stream SFMain object is returned to the application. Then it is able to read/write the file/stream, treat it as set of records or just sequence of bytes.
SFStorage - Abstract directory. This is used to access directories or other directory like resources (such as the sub-storages in the OLE compound files).
SFFileStream and SFDirStorage - Low level implementation of the Stream and Storage abstraction for files and directories. Scripting applications do not need to use these objects directly. However C++ and VB applications may need them to simplify parts of code dealing with different resources that met the stream and storage abstractions.
SFDrive - represents a logical drive on the machine. E.g. C:, D: etc.
SFInfo - Returned when information for file, stream, directory or another storage is requested. Contains information for the item (such as size, name etc.).
SFRecord and SFField - Together they form structure/record definition for use with binary files and streams. A scripting application (such as ASP application) could define a record of fields (e.g. values with predefined type) and read/write them from/to binary files or other streams. A random access is provided thus the application is able to read/write records at any position within the file (or stream) by using methods very similar to the ADO's recordset object. Using this feature data can be stored in DB-like files or binary formats otherwise not accessible for the scripting applications could be managed and supported. For example DBF files, bitmap images etc.
SFFilter - Used by the above objects (SFRecord and SFField). This is the abstract level between the binary file and logical records. The library contains only one - the default filter currently but more can be developed (inside or outside - in external DLLs) to provide pre-coding when the data from the logical records and fields is written or read to/from the file or stream. For example this filter converts UNICODE strings to ANSI and vice versa as requested by setting the filter's properties. Another filter could be needed if data must be read from a file saved with Macintosh byte order for example. In other words this gives us and the other developers to solve any encoding problem by developing a filter for the case. In Windows world the default filter is enough for almost any purpose. It could be used also if single values must read or written from/to binary stream (not using records and fields). The scripting developers need to access only a little part of the SFFilter object and it is available through the SFRecord object, thus SFFilter remains transparent unless advanced techniques are required.
TypeConvertor - Type converter and bit wise operations. Contains methods that implement strict type conversion and bit wise logical operations. Some script languages lack of such functionality and you may need this object to solve the problem (for example VBScript have no bit wise operations, JScript has no strict type conversion implemented).
Universal collections. These objects are use by various other products and components including products from other vendors. In many cases collections of strings or another items must be managed/returned/passed as parameter. Or tree(s) of items must be passed from one component/application to another. These two collections are applicable and powerful enough to meet the requirements of many different kind of applications. Using them instead of implementing custom collection each time saves a lot of work and also provides the other developers with common programming interface. We are using them wherever they are applicable. If you need something similar check the applicability notes.
VarDictionary collection - Keeps items in VARIANTs. The items could be named and unnamed and the collection behavior could be tuned to the application/component requirements. Items kept could be anything the VARIANT type allows (for example scripting applications work internally with VARIANTS, thus an ASP application for example will be able to put any item in such a collection). This means the items could be numeric, string values, arrays or objects. Trees of items could be created by keeping items that are another VarDictionary objects - e.g. a collection of collections could be constructed. VarDictionary supplies various methods and properties useful for wide range of operations from operations typical for simple collections to operations required when the collections form a tree (collections of collections and other items).
UtilStringList - Additional collection tool that keeps only strings and provides access to them by number or numeration (For Each ...). All the assigned values are converted to strings. Such a behavior is often needed - for example when an item from another collection must contain many values (Request.Form, Request.QueryString in ASP/ALP are good example - they could keep several strings under each name if the controls with this name are more than one in the WEB page submitted the request).
Configurations, registry and INI Files. These components provide access to resources usually treated as configurations by the applications. However the ConfigFile component has very advanced features and could be used for structured data transfers through streams. A replacement/alternative for it - much easier for use will be added to the library very soon.
INIFile - allows access to the INI files in the manner exposed by the Win32 API. I.e. this is wrapper for the Win32 API functions and makes them accessible for the ASP pages and other scripts. When management of the INI files requires modification without disturbing the resting entries in it (e.g. when generating file is not what you want) - the component will be a perfect solution.
ConfigFile - Provides access to newObjects structured configuration files (for example ALP configurations, ALPInstall configuration and so on), registry and binary format using the VarDictionary collections to represent the data as structured tree. Because of the different requirements of the different storages usage could be a little confusing at the beginning. For example Windows registry cannot keep floating numbers as values thus such a value stored in the data tree will make it unsaveable into the registry. Thus usage requires developer to pay attention to convert the values stored in a data tree according to the capabilities of the storage medium. However the basic types - such as integers and strings are supported by all the storages thus not forgetting to use conversion functions (such as CInt, CStr in VBScript) solves the problem and gives the developer the opportunity to deal with registry, (textual) structured configuration files and binary streams in the same manner. However we are going to supply new implementation of this component (keeping this one intact) that will make the above conversions and capability tests automatically. Compatibility between the formats is guaranteed thus the everything saved with the ConfigFile component will be possible to read and write with the new one.
Composite objects. This set of components allows the developer to pack scripts and objects together and expose them as whole single object to the world. The creation can be dynamic or can be made through the system COM functions (as like the MS WSC). Although many similarities can be found between the composite objects and the Microsoft Windows Script Components there are a lot of differences and application targets.
VaryDisp - Dynamic creation of composite objects
VaryDispCreator - Create pre-defined composite objects, register them as normal COM objects etc.
And other supporting objects.
Advanced COM. This set of components allows you to create threads, instantiate objects in controlled COM environment, solve component requirements in autorun scenarios (where the system is unable to help) etc.
When used with other application we strongly recommend the following install location:
%SYSTEMDRIVE%\Program files\newObjects\ActiveXAll the setup products allow you to choose the destination for a DLL. Placing this DLL in the above location will guarantee the version checking and avoid any duplication of the DLL file. We strictly keep the compatibility between the versions thus it is not only safe but recommended to replace the older versions of the DLL.
Requirements: Windows 95/98/ME/NT/2000/XP or later. On Windows 95 only: DCOM update is required if the components will be created as free-threaded or remotely (If Internet Explorer 4 or later is installed there is no need of additional update).
Dependencies: The DLL is self-dependent. It needs only standard system features available on all the x86 Win32 platforms. Components related to manipulation of external features (such as ScriptManager2) require the script engines to be installed. A few words about them (you can learn more details on the Microsoft's site) JScript 3.0 and VBScript 3.0 are available with Internet Explorer 4.0, 5.0 versions of these engines ship with the IE 5.0 and so on. Note that run-time libraries (such as FileSystemObject) are not installed with Internet Explorer! The newobjectspack1.DLL supplies much more powerful components for the same purposes and using them will give your application not only power but will make it also independent!
If used with ALPFrame for autorun CDs (e.g. the DLL is not installed, nor registered in the system registry) the DLL must be registered in the alpframe.cfg file (see ALPFrame documentation for samples and additional details).