Low cost ecommerce web development India flash website design

Built-in COM Objects

There are six built-in COM objects in the ASP environment:

§ Server

§ Request

§ Response

§ ObjectContext

§ Application

§ Session

The difference between these COM objects and the others is that you do not

need to create an instance of these objects to call them. Built-in objects are

present in the page without instantiation. They adhere to all the other rules of

COM and have their own methods and properties. You do not need to know

their ProgIds because you don't have to call the CreateObject method to

instantiate them.

ProgId

If one of the major ways to create a COM object is by using the

CreateObject method, knowing the ProgIds of the objects you are creating is

very important. So where are the ProgIds located? The component vendor

should supply the component ProgIds as part of the documentation.

However, not all ProgIds are supplied, because a vendor doesn't always want

you to create an instance of the object using the CreateObject method. Some

objects inherit properties from the object that creates them, so if they are not

created from calling a method in that object they are not initialized correctly.

For example, creating an instance of an ADO Field object would not do you

much good without going through the RecordSet object, because the ADO

Field object would not contain any data unless you went through the

RecordSet object.

Further On ...

In a booklet as brief as this, there is not much scope to include how to write

your own COM objects. The idea is to use languages such as Visual Basic

(not the scripting language VBScript) or Visual C++ (or any language that

allows you to generate Win32 COM objects).

COM objects, as you must have noted, are typically compiled code. Hence

they execute faster than ASP scripts. In a complex project with stringent

efficiency requirements, you might want to code the Business Rules layer in a

COM object rather than ASP scripts.