Defines the most important settings for the ASP pages.

Default language: The scripting language which will be assumed if the page does not contain @Language option.

IIS Compatibility: ALP 1.1 supports 4 levels (0,1,2,3). For new applications it is recommended to use the biggest. However applications written for earlier ALP versions may need lower compatibility level. What this means? ASP support in ALP resembles the ASP support in IIS. However there were some differences in the ALP behavior which can be controlled by setting the compatibility level. In one word higher compatibility level means closer IIS behavior. Older ALP application may still need the mentioned differences so the level can be set for each application. The most important behavior elements affected by the compatibility level:

Level 0:

• The empty/non-set variables in the Application and Session are set to NULL (VT_NULL)
• When missing value is referred from the Request directly ( type of Request("MissingParameter") is empty string ) the returned empty collection returns empty string for its root value.

Level 1:

• The empty/non-set variables in the Application and Session are set to Empty (VT_EMPTY)
• When missing value is referred from the Request directly ( type of Request("MissingParameter") is empty string ) the returned empty collection returns empty string for its root value.

Level 2:

• The empty/non-set variables in the Application and Session are set to Empty (VT_EMPTY)
• When missing value is referred from the Request directly ( type of Request("MissingParameter") is Empty/undefined ) the returned empty collection returns empty variant for its root value.

The other options control the error mode, maximum time allowed for one page processing etc.

Special attention deserves the Extended CreateObject option. If you set it on the Server.CreateObject and <OBJECT RUNAT=SERVER ...> will use the CreateObject method supplied by the Pack1Creator object from the ALP Run-time library. This opens interesting opportunities and is especially useful for autorun applications which cannot afford to register the components they need. If it is enabled you will be able to specify not only ProgID or ClassID in the Server.CreateObject, but also path to a composite object definition file and even create objects from COM DLL which is not registered with the system (note  that most COM DLL-s will not function correctly that way, we can guarantee that this works with our components, but we strongly recommend you test any 3-d party component before using it that way).

See also the COM map aliases. They allow own/custom ProgID-s to be used for the COM objects and allow the applications developed for autorun scenarios to avoid using raw ClassID-s.