The special ASP objects are advised when created for the ASP objects (Request, Response, etc.). Thus they are able to fetch, put data directly to the ASP engine without help from the script on the page that created them. In many cases this may simplify the project by reducing the code needed because the objects are able to get what they need on their own and the script in the ASP page will not need to transfer values from the environment. It is obvious that this technique is most useful for objects specific for aparticular project and not for universal utility objects (except a few rare cases).

How this works:

In a regular ASP page whenever an object is created using the Server.CreateObject or the <OBJECT RUNAT=SERVER ... > tag the object is checked for two methods that can be implemented in it: OnStartPage and OnEndPage. They are expected to be IDispatch methods (also called automation methods). If they exist they are called - the ObStartPage before the page processing begins and the OnEndPage after the page finishes its work.

The prototypes are:

VB notation:
Sub OnStartPage(ctx)
and
Sub OnEndPage()

C++ notation:
HRESULT OnStartPage(IDispatch* context);
HRESULT OnEndPage();

The OnEndPage is not required - if the object has nothing to un-initialize it can be skipped.

The context (ctx) variable passed to the OnStartPage contains an ALPScriptingContext object which has these read-only properties: Application, Session, Request, Response, Server. All they return the corresponding ASP object. The returned value is of type Object (VBScript), IDispatch* (C++).

Note that you should NOT use the types ScriptingContext or Request, Response and the others known from the classic ASP! ALP is not binary compatible with the classic ASP and you must refer to the objects only through automation (IDispatch) interface. In VB this even saves some writting  -you do not need to specify the type name - just use un-typed variable. In C++ you must use IDispatch::GetIDsOfNames and IDispatch::Invoke to call the context's and the ASP objects' properties and methods. The objects built after this fashion will be compatible with both classic ASP and ALP and even with 3-d party ASP engines.

How to build ASP objects?

You have many options. We will point out how to proceed using some of them.

VB: Create a standard ActiveX DLL project. Implement one or more classes in it. In each class implement the OnStartPage and if needed OnEndPage method. Preserve the received context variable in the OnStartPage method for example:

Sub OnStartPage(ctx)
  Set SomeClassVariable = ctx
...
End Sub

Then use ctx.Request, ctx.Server and so on whenever you need to access the ASP objects directly from your class.

C++: The best way is ATL. Create an ActiveX DLL project and implement the required methods. To simplify the IDispatch calls to the context object you can use the DSIPCALLER C++ class supplied with ALP (see in the SDK resources directory in the ALP installation folder). If you are building explicitly for ALP you can import the ALP type library and use the IALPScriptingContext interface, but do not forget this will be ALP specific.

Composite objects written in script: The ALP run-time library supports the so-called composite objects. With them you can create COM object entirely in script. This technique has a similar equivalent you may know - the Windows Scripting Components from Microsoft. However the ALP composite objects are dynamic and may run without installation (e.g. they can be used in autoruns for example - not necessary to register them). Also they can be created directly from their definition file which makes this very useful if you do not want to install huge amount of COM objects with a setup program (see the composite objects part of this documentation for information on how to build components in script) . To support this ALP supports a specific setting for the ScriptGen (ALP's ASP engine module) content generator - ExtendedCreateObject. If available and set to non-zero integer value it causes ALP to try to create objects in all the possible ways: CLSID, ProgID, composite object definition file, directly from DLL by CLSID. You will need to set it if you want to be able to create composite objects directly from Server.CreateObject or <OBJECT> tag not registering them as regular COM objects. This extension allows you to use in the CreateObject and the <OBJECT> tags parameters like "C:\somepath\somepath\compositedeffile.ext" (and Server.MapPath them of course). This way they will be initialized and asked for OnStartPage event if they support it. Without this extension enabled you can specify only ProgID or ClassID in the create object routines/tags. See also the ScriptGen configuration and the Pack1Creator.CreateObject (the parameters described there can be used directly in Server.CreateObject if the extension is enabled, the default flags are 0).