newObjects (fromerly known as ZmeY soft) newObjects ActiveX Pack1 (AXPack1)
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

ASP Index

Site navigation
ActiveX components

Binary and flat files

with ActiveX Pack1 ASP application is able to not just read/send binary files. They can be accessed as set of applciation defined records. And this is not limited to the files - any resource that behaves like file can be treated as like a DB table - memory streams, files, streams in OLE Compound files and so on.

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

PADRING: Always new software

Quick contact

Web development portal

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

 newObjects ActiveX Pack1 (AXPack1)   
Price: FREEWARE Discount for resalers FREEWARE
Information Download Buy
Storages and Files
Hosting Active Scripts
Config, INI files and Registry
AXPack1 family samples
Download (SFX 1.8MB PC/PPC)
Download (ZIP 3.1MB PC/PPC)
PC Only (SFX 0.8M)
PC Only (ZIP 1.2M)
CAB (Pocket PC ARM)
CAB (Pocket PC SH3)
CAB (Pocket PC MIPS)
All the downloads

Config, INI files and Registry

While the ASPIniFile component is included for backward compatibility and support for applications that "understand" only INI files, ConfigFile object goes further. It supports so called (internally) Unified Structured Data (USD). USD is just a thing every programmer needs one day. Many programmers waited for XML - we not. We used it for many years in our C++ application, but ConfigFile makes it available for script applications.

Abstract data structure defined by USD is a tree of data. It consists of Sections, Records and Values. Each section may contain subsections and records. Each record may contain one or more values (named or unnamed). The values are strictly typed - e.g. their type is known and this makes them more convenient for pure programming purposes than the document oriented XML. The ConfigFile represents the data using VarDictionary collections. When data is loaded from a certain source it appears to the application as a tree - collection of collections. Then the application may walk the tree, search through it and use/alter the contained values, add/remove parts of it, clone some branches and so on.

What are the benefits? Current version supports 3 formats - textual, binary and Windows registry. This means the application is able to obtain its data from different sources but packed in the same manner!  The other benefits are the structure - tree like structure allows any complexity of the configuration. INI files do not support sub sections for example. The parts of different configurations can be cut/copied and moved to another configuration and then saved somewhere. If the object is created as free threaded then the loaded data can be assigned to an Application or Session variable in ASP. This allows to load it once and keep it in memory, thus treat it as some kind of memory data base. Let us take a little sample.

Load the data (probably in global.asa):

Set CfgObj = Server.CreateObject("")
' Load some data.
' From a text file
Set Application("TextConfig") = SfgObj.Read(Server.MapPath("config.cfg"))
' From registry
Set Application("RegConfig") = SfgObj.ReadFromRegistry(cRegLocalMachine, _
' From a binary file
Set sf = Server.CreateObject("newObjects.utilctls.SFMain")
Set f = sf.OpenFile(Server.MapPath("somefile.bin"))
Set Application("BinConfig") = SfgObj.ReadFromBinaryStream(f)
' Save the CfgObj in Application
Set Application("ConfigFile") = CfgObj

And let use some a data tree in a regular ASP page

Set cfg = Application("RegConfig")
' Get the DB init string for example
db.Open cfg("DataBase")("InitString")
' Enum the values in a branch
For I = 1 To cfg("Names")
  current = cfg("Names")(I)
  ' Do something with it
' Set a value
cfg("Settings")("FontSize") = 7
' Create a branch. In this case if we save 
' it back to the registry it will create a key, 
' if it is saved to text file the branch will 
' correspond to a { Section ... }
Set newSection = Application("ConfigFile").CreateSection
' See above - we saved the object to an Application variable
' for convenience.
' Now add something to the section
Set rec = Application("ConfigFile").CreateRecord
rec("Alpha") = "something"
rec("Beta") = 100
newSection.Add "Record1",  rec
cfg("Settings").Add "NewBranch", newSection
' Well but the system registry does not support such thing
' like Value "Record1" with two sub values named "Alpha" and "Beta"
' Thus with this we made it impossible to save it back to 
' the registry, but the other formats are still available. 
' To make it good for the registry we can use another way
Set newSection = Application("ConfigFile").CreateSection
newSection("Alpha") = "something"
newSection("Beta") = 100
' We skipped the record creation and this is legal. It will prevent
' us from assigning many values to each record, but this is enough
' in the most cases and is much shorter.
' What about many unnamed values in one record?
Set newSection = Application("ConfigFile").CreateSection
Set rec = Application("ConfigFile").CreateRecord
rec.Add "", "Blah"
rec.Add "", 100
rec.Add "", 3.14
newSection.Add "MyRecord", rec
' Now what will return the:
aVariable = newSection("MyRecord")
' The first value - it is "Blah" in this case
' If we want  to reach other value
aVariable = newSection("MyRecord")(3)
' Will return 3.14
' Note that this is not compatible with the system registry too
' In general the registry supports a subset of the types 
' and capabilities of the USD thus we cannot keep
' the data tree an actual copy of the registry branch
' and use all the features at the same time. However
' this limitation is much less important than the benefits.

Script programmers should be careful when assigning values. VarDictionary will permit any kind of value, but not all the values can be saved. For example imagine an object - there is no way to understand how to save it or what to save the object or its default property. Therefore you will need to use strict type conversion when assigning/adding values in cases where the type conversion is ambiguous. This comes from the C++ roots of the architecture. To keep the size of the object small it uses the VarDictionary for data representation. We are going to supply later this year more powerful version of the object which will coexist with this one but in a separate DLL. Thus treat this version as light weight way to access the USD data and please excuse us for the little inconvenience caused by the need to use the CLng, CDbl, CStr etc. functions too much.

Copyright newObjects (ZmeY soft) 2001-2005