Using the code is fairly simple. Just include the "WebControl.asp" file and a reference to each Server Control (example: Server+CheckBox.asp) that you want to use to your ASP page. After you include the references then you need to write code inside each event you want to handle (Page level or postback events).

Include FormStart.asp when the form starts and FormEnd.asp when you need to close the form tag. This two includes will make sure that all necessary hidden fields are included. The last thing that has to be done is to the Main() method (included in the WebControls.asp). This method will do the magic. I call it the "Page Controller" because it coordinates the execution of all the events in the appropriate order. This method should only be called after the declaration of all the includes and BEFORE rendering any control.

The Framework includes several examples that show how it works.

WebControl.asp contains the core classes: WebControl, ControlsCollection, Page, ClientEvent and a few utility functions. All controls "inherit" from WebControl (including the Page class). Now, wait a second, inherits in VBScript?. Not really, I "simulated" inheritance by having each WebControl variable inside each Server Control.

In addition to this, you need to register one COM Comnponent (ASPFramework.dll) which is used to encapsulate the ViewState (which is XML), the Base64 functions and the ListItemCollection. It is a VB Class and the source code is provided. The only reason for using a VB Class is for speed purposes. We don't want to encrypt/decrypt in VBScript!

Below is the list of events that are currently supported at the page level (if they are present then they will be executed)

• Page_Authenticate_Request
• Page_Authorize_Request
• Page_Init
• Page_Controls_Init - Occurs just once, when the page is first loaded!
• Page_LoadViewState
• Page_Load
• Page_HandleClientEvent
• Page_PreRender
• Page_SaveViewState

This are the events supported by custom Server Controls (when creating your own controls). Look at one of the controls such as Server_CheckBox or Server_HyperLink to see how easy is to write your own control!

• OnInit
• OnLoad
• ReadProperties(PropertyBag) - To read your persisted properties in the viewatate
• WriteProperties(PropertyBag) - To write your properties to the viewstate
• HandleClientEvent(event) - To handle events if the object is target of a postback

Other cool features are

• Page.AutoResetScrollPosition - used to restore the vertical scroll position between postbacks
• Page.AutoResetFocus - used to reset the focus to the last control souce of a postback (which can be overrided!)
• Page.DebugEnabled - To keep track of a bunch of information that is displayed at the end of the page (like tracing in .NET). You control the details level using Page.DebugLevel (1-3)
• Page.CompressFactor - Set to -1 for no compress, and > 0 to compress if ViewState size > CompressFactor bytes
• Page.ViewstateMode - used to control the location of the viewstate. Can be set to VIEW_STATE_MODE_CLIENT or VIEW_STATE_MODE_SERVER. If VIEW_STATE_MODE_SERVER then the viewstate will be persisted in the VS session variable!
• Page.IsRedirectedPostBack - This property indicates if the page was called from another asp page and it has event information in the form... VERY useful to pass parameters between pages and avoid the use of the QueryString!

The postback events are usually captured by writing a function using the following format: controlName_eventName([event]). For instance, if you click on button with name cmdSave then you would capture this event on the server side by creating a function such as: cmdSave_OnClick()

The Framework supports viewstate, so you can use Page.ViewState.Add(key,value) and Page.ViewState.GetValue(key). Each control also supports viewstate through Control.EnableViewstate = (true/false)

On the next few pages, we'll show a few screen shots, and the source code that was used to create them.