I always forget the exact order in which events fire. So i found the following when i googled and wanna share it with you all :)

Page.Init + Control.Init for every control on the Web Form
The first stage in the page life cycle is initialization. After the page's control tree is populated with all the statically declared controls in the .aspx source the Init event is fired. First, the Init event for the Page object occurs, then Init event occurs for each control on the Page. Viewstate information is not available at this stage.

Page.LoadViewState
After initialization, ASP.NET loads the view state for the page. ViewState contains the state of the controls the last time the page was processed on the server.

Page.ProcessPostData
Post Data gets read from the request and control values are applied to control initalized in stage 1.

Page.Load + Control.Load for each control on the Page
If this is the first time the page is being processed (Page.IsPostback property), initial data binding is performed here.

"Change" events are fired for controls
(TextChanged, SelectedIndexChanged, and similar) The current value (from Post Data) is compared to the original value located in the ViewState. If there is a difference "Changed" events are raised.

Server-side events are fired for any validation controls
Button.Click + Button.Command
The Click and Command events are fired for the button that caused the postback

Page.PreRender + Control.PreRender

Page.SaveViewState
New values for all the controls are saved to the view state for another round-trip to the server.

Page.Render

Patrick Tisseghem was going to speak about SharePoint site definitions and templates on the TechEd 2005 in Amsterdam, but his session agenda has changed. He will be speaking about another very interesting session:

Creating Dynamic Web Sites with ASP.NET 2.0 Web Parts
"Drill down on the new Web Parts infrastructure in ASP.NET 2.0. Learn how you can use Web Parts to build rich Web sites- enabling end users to dynamically control the layout of pages-and customize the properties of server controls."

We already had a session internally about this subject given by Mart. I will certainly be there as SharePoint Geek! :)

http://blog.u2u.info/DottextWeb/patrick/archive/2005/06/09/4311.aspx

public class ImageFolderViewer : System.Web.UI.UserControl
{
    int horizontalImageCount = 4;
   int imageWidth = 120;
   int imageHeight = 80;

   ...
}

In the Page_Load of the class we call the GenerateImageView method to generate the images in the view.

private void Page_Load( object sender, System.EventArgs e)
{
   GenerateImageView();
}

The following property is used to set or get the number of horizontal images per row.

public int HorizontalImageCount
{
    get
    {
       return horizontalImageCount;
    }
    set
    {
      horizontalImageCount = value ;
   }
}

These properties are used for remembering the current folder and the original folder and are kept in the ViewState. The original folder is the first folder set to the control. We use the original folder to define when i link is displayed for moving a folder up.  

private string OriginalFolder
{
    get
    {
       return ViewState[ "originalFolder" ] != null ? ViewState[ "originalFolder" ].ToString() : "" ;
   }
    set
    {
      ViewState[ "originalFolder" ] = value ;
   }
}

public string Folder
{
    get
    {
       return ViewState[ "folder" ] != null ? ViewState[ "folder" ].ToString() : "" ;
   }
    set
    {
      // store the original folder in the viewstate
       if (OriginalFolder == "" )
      {
         OriginalFolder = value ;
      }

      ViewState[ "folder" ] = value ;
   }
}

The GenerateImageView is the engine of the class and generates all the images and subfolders. A seperate method GenerateDirectoryLink is used for generating the link and its argument per subfolder.

private void GenerateImageView()
{
    string imagePath = System.Web.HttpContext.Current.Server.MapPath(Folder);

   // check if the folder exists
   if (!Directory.Exists(imagePath))
   {
       return ;
   }

   TableCell cell = new TableCell();
   row.Controls.Add(cell);
   cell.ColumnSpan = HorizontalImageCount;

   LinkButton btn = new LinkButton();
   btn.Text = text;
   btn.CommandArgument = argument;
   btn.Click += new EventHandler(FolderButton_Click);
    cell.Controls.Add(btn);
}

When a link of a subfolder or "One folder up" is pressed an event is fired. The Folder property is set to the new folder and the view is generated again. 

private void FolderButton_Click( object sender, EventArgs e)
{
   LinkButton btn = sender as LinkButton;

   Folder = btn.CommandArgument;

   GenerateImageView();
}

Another problem is that if the images are large it will take some time to place them in the view. There are several solutions for this problem.

• You could create a thumbnail per image and refer the Image class to the thumbnail instead. The thumbnail is only generated once. So it will only be slow the first time
• Use a third-party tool like ASPJPeg which does the resizing for you.

Ofcourse there are more solutions but i thought that these two would be nice to tell about.

This is a very simple example how to transform a Webform.aspx file to a wizard. It contains two buttons and works even when the back and next button of the browser are used.

We keep the current page stored in the ViewState. The method ShowPage() should contain the functionality to show the contents of a wizard page. You could use a PlaceHolder per wizard page and show/hides these PlaceHolders.

   ShowPage();
}

private void ShowPage()
{
   lblPage.Text = CurrentPage.ToString();
}

private void InitializeComponent()
{ 
   this.btnPrev.Click += new System.EventHandler(this.btnPrev_Click);
   this.btnNext.Click += new System.EventHandler(this.btnNext_Click);
   this.Load += new System.EventHandler(this.Page_Load);
}

private int CurrentPage
{
    get
   {
      object page = ViewState["CurrentPage"];

      if (page == null)
      {
         ViewState["CurrentPage"] = 0;
      }

      return Convert.ToInt32(ViewState["CurrentPage"]);
   }
    set
   {
      ViewState["CurrentPage"] = value;
   }
}

private void btnPrev_Click(object sender, System.EventArgs e)
{
   CurrentPage--;
   ShowPage();
}

private void btnNext_Click(object sender, System.EventArgs e)
{
   CurrentPage++;
   ShowPage();
}
}

When you create a property in your WebPart and give it some extra attributes it will appear as a control when you modify your WebPart. The following code is an example:

[Browsable(true),
Category("Customer"),
DefaultValue(0),
WebPartStorage(Storage.Shared),
FriendlyName("Customer ID"),
Description("Fill in the customer ID")]
public int CustomerID
{
   get
   {
      return customerID;
   }
   set
   {
      customerID = value;
   }
}

This example creates a category named "Customer" with one field. the FriendlyName(..) is used as description for the field and the Description(..) is used as tooltip text. When no value is set the DefaultValue(..) is used as default value. In this case the field contains a zero.

When you use properties you only have a few possibilities. Checkboxes are used for booleans, Text fields are used for doubles, int, strings, etc and a dropdownlist is used for enumerations.

So why not create your own ToolPart with default and/or your own controls? It is even not that difficult. :)

I'm working on a BirthdayWebPart which needs some functionality to select through a dropdown box the contact list. But only enumerations are shown using a dropdown list. So we have to write our own ToolPart.

First we create a new class derived from the class Microsoft.SharePoint.WebPartPages.ToolPart. You could do this by hand or use the wizard in Visual Studio.

public BirthDayToolPart : Microsoft.SharePoint.WebPartPages.ToolPart
{
   private DropDownList ddlList = null;

   public BirthDayToolPart()
   {
      ...
   }

   public override void ApplyChanges()
   {   
      ...
   }

   protected override void RenderToolPart(HtmlTextWriter output)
   {
      ...
   }      
}

We will create and initialise the DropDownList in the constructor of the class. The DropDownList is filled with the list of available ContactLists.

public BirthDayToolPart()
{
   ddlList = new DropDownList();
   ddlList.ID = "ddlContactListName";
   Controls.Add(ddlList);

   SPWeb currentWeb = SPControl.GetContextWeb(Context);
   foreach(SPList list in currentWeb.Lists)
   {
      if (list.BaseTemplate == SPListTemplate.Contacts)
      {
         ddlList.Items.Add(new ListItem(list.Title, list.Title));   
      }
   }
}

Now we have to render the DropDownList to the client by overloading the RenderToolPart. We first retrieve the selected web part. Because this ToolPart belongs to the BirthDayWebPart we can cast it to this class. The property ContactListName of the BirthDayWebPart is used for getting the currently selected ContactList. The code is as follow:

protected override void RenderToolPart(HtmlTextWriter output)
{
   BirthDayWebPart webPart = ParentToolPane.SelectedWebPart as BirthDayWebPart;

   ddlList.SelectedValue = webPart.ContactListName;
   ddlList.RenderControl(output);

   // render other controls and/or write html to the client
   ...
}

Last but certainly not lease we override the ApplyChanges for storing the data back into the BirthDayWebPart. Here we set the ContactListName by using the property of the BirthDayWebPart class.

public override void ApplyChanges()
{
   BirthDayWebPart webPart = ParentToolPane.SelectedWebPart as BirthDayWebPart;

   webPart.ContactListName = Page.Request.Form[ddlList.ClientID];

   // store content of other controls
   ...
}

The next step is telling the BirthDayWebPart to use the ToolPart. We override the member GetToolParts() in the BirthDayWebPart as follow:

public override ToolPart[] GetToolParts()
{
   ToolPart[] toolParts = new ToolPart[3];

   toolParts[0] = new CustomPropertyToolPart();
   toolParts[1] = new WebPartToolPart();
   toolParts[2] = new BirthDayToolPart();

   return toolParts;
}

The CustomPropertyToolPart represents the default ToolPart that is displayed in the tool pane for a web part that implements one or more custom properties. Like for example a field containing the number of days to look forward.

The WebPartToolPart class represents a ToolPart that can be used to show or modify web part base properties. Like the minimize and title properties.

The third ToolPart is our own created BirthDayToolPart.

I found a great article on SharePoint Thoughts posted by pBoy about adding a custom ASP.NET application into a site template. It describes in a few steps how to do this. Some knowlegde is needed because you will be modifying the ONET.XML. Follow the link below for the whole article:

http://www.bluedoglimited.com/SharePointThoughts/ViewPost.aspx?ID=167

I expect that there are a lot of people who already wrote some knowlegde article about this. But it never hurts to explain it again. When you use Response.Transmitfile for transmitting a file to the client it gets the name of the current aspx file.

So how do you set the default name of the file which is downloaded to the client? It is actually very easy. The following code downloads a word file "rapport.doc" to the client:

string pathFileName = @"c:\documents\rapport.doc";
string fileName = System.IO.Path.GetFileName(pathFileName);

Response.ContentType = "application/msword";
Response.AddHeader("Content-Disposition", "attachment; filename=" + fileName);
Response.TransmitFile(pathFileName);

I like to use singletons in my applications, especially when i don't want to initialise a class all the time when i need it. The idea behind a singleton class is to get an instance by calling a static member method and not be able to instantiate the class yourself. In that way there will only be one instance of the class during the run of the application. This is accomplished by making the constructor protected. Normally a singleton class is used in a windows application as follow:

class SomeClass
{
   private static SomeClass instance = null;

   protected SomeClass()
   {
   }

   public static SomeClass Instance
   {
      get
      {
         if (instance == null)
         {
            instance = new SomeClass();
         }

         return instance;
      }
   }
}

When you want to use the same trick in an ASP.NET application it will not work, because everytime the class is destroyed when the content of your page is rendered to the client. But even singletons are usefull in ASP.NET applications and there is a solution by using for example the session state. The following code shows you how:

class SomeClass
{
   protected SomeClass()
   {
   }

   public static SomeClass Instance
   {
      get
      {
         object instance = System.Web.HttpContext.Current.Session["SomeClassInstance"];

         if (instance == null)
         {
            instance = System.Web.HttpContext.Current.Session["SomeClassInstance"] = new SomeClass();
         }

         return instance as SomeClass;
      }
   }
}

As you can see it just stores the instance in a session state. You could even store the instance in the application state if there is need for. It could be helpfull for your ASP.NET application. :)