Much similar to a TForm object, a Web Form exposes events that are fired in a logical and predictable sequence. However, there is ONE big difference. In classic desktop applications, all events (triggered by actions on a client) are handled by event handling procedures on a client. In asp.net, events are triggered in the client browser, but are handled in server code.

Web Form Properties

  if not IsPostBack then
  // only first time
  begin
    ListBox1.Items.Add('http://delphi.about.com');
    ListBox1.Items.Add('http://aspxDelphi.net');
    ListBox1.Items.Add('http://www.mono-software.com');
  end;

The IsPostback is a readonly, runtime only property. The IsPostback is used to detect whether the page is being loaded in response to a client postback (IsPostback = True), or if it is being loaded and accessed for the first time (IsPostback = false).

Postbacks and the stateless nature of web applications
In the above code, the IsPostback check guaranties that the ListBox will be filled with predefined items only the first time the page is accessed. Something called the "ViewState" will ensure that the content of the list is maintained on subsequent postbacks.

Let's take a quick look at what a postback is. First, note that it's still to early for us to discuss topics like postbacks, managing the view state, page execution stages; but it's just the time to introduce the idea of the postback processing.

One of the big differences between standard desktop applications and web applications is that asp.net web applications are stateless in their nature. When a Web server receives a request for a page, it processes the page, sends it to the browser, and then discards all page information. As a result, a web page must be regenerated from scratch for every round-trip. A round-trip is a sequence of the following steps (simplified):
1) Web browser requests the data from the server; server serves the HTML page.
2) A user enters some data in the web form elements; the data is sent to the web server.
3) The results are sent back as a HTML.

Provided with the above discussion, a postback is a round trip to and from the server when the page that "generated" the request is the same as the page that processes the respons from the server. In other words, the page request is posted back to itself. In asp.net the most common postback causes are button clicks. Every button on a web form raises a postback.

The all mighty "ViewState"
There are many ways you can preserve the state of a web page - luckily much of the work is done behind the scenes. All web controls and html control (we are to discuss in the coming chapters) can maintain their state (associated values, like items of the ListBox) between round-trips (page postbacks) without any coding effort on your part. This is called the view state.
When you run your application, after the page is displayed in the web browser, select View - Source to see the "raw" HTML. You should locate the _viewstate hidden form field. This hidden field is auto-generated by asp.net for every .aspx web page. The encoded value string contains information about the state (values) of all the web controls on a web page. When the page is posted back to the web server (a postback) the value of the _viewstate hidden field is used to populate the controls with their values. Now if a user has changed a value in any web control (a TextBox for example) the value from the _viewstate will be compared with the new value in the TextBox to optionally raise the Change event (for example).

The above explanation is far from being the full explanation of postbacks, view state and state management. However, this should be enough for us to proceed to more advanced topics.

Web Form Events

"Warning"
In Win32 all events have the "On" prefix, like OnClick, OnChange, etc. In .Net all events lack the On prefix. Events are called Click, Change, etc. The OnClick is a protected event raising method - something like the protected DoChange method often found in the VCL sources. I'm not going to discuss this issue here ... for the moment just try not to be confused when you see an event called Click and not as you would expect OnClick.

When you ask a web server for a web page (navigate to an aspx page), the asp.net engine will execute the class for the web page (after being compiled if necessary). The following events will fire, on a first call to a web page:

1. Init, which occurs when the page class is initialized. Note that Delphi automatically adds an overridden OnInit method to your web form's code. This is NOT the event handler for the Page's Init event. If you want to add code inside the Init event handling procedure you should create using the Object Inspector (the same way you create event handling procedures for Win32 applications). Furthermore, you should not access server controls (in the page control hierarchy) during this event; since the view state is not yet populated.

2. Load, this event is typically used for initializing controls, variables and other objects. You can safely access page's server controls. Note: the Load event handling method's skeleton is auto-created by the Delphi IDE when you add a new page to the web application.

3. PreRender, occurs when the page is ready to be rendered to the browser.

4. Unload and Disposed, occur as final events in a page life-cycle.

Note: on a second (third, ...) call for the same page (after a postback), numerous control-specific events may also occur.

There are other events that you can handle for a web page, but the most interesting could be Error and DataBinding. Error event is fired when any unhandled exception is raised in the web form. You could you this event to redirect the user to a special page where you can display the error in a more friendly way. Notice, however, that errors and exceptions inside the entire web application can be handled using the web.config file. Again, this is something we'll discuss later.

Events and their "signature"
Take a look at the Load event handling method's declaration:

procedure TWebForm1.TWebForm1_Load
  (sender: System.Object; e: System.EventArgs);

All events in .Net, in general, accept (or provide) two parameters. The first one, Sender, is a reference to the object that generated the event - much similar to classic Win32 Delphi. The second parameter, e of type System.EventArgs (or a type that extends System.EventArgs) provides additional event arguments. The System.EventArgs, in particular, contains no event data.

Web Form Methods and Properties

That's it for today. We are, more or less, done with the introduction to web forms. The time has come to take a deep breath and dive into the world of HTML and Web controls ....

To the next chapter: A Beginner's Guide to Asp.Net Programming for Delphi developers

If you need any kind of help at this point, please post to the Delphi Programming Forum where all the questions are answered and beginners are treated as experts.