Step 2:
We need a way to close the dialog reliably.  Response.Redirect() won't work for obvious reasons.  Inside the event that will close the dialog, normally a "cancel" button click, register script that will close the window.  If you have multiple ways to exit the dialog, you might want to create a seperate method and call it from each event.

string strScript = "<script language='javascript'>self.close(); </script>";
if (! this.IsClientScriptBlockRegistered("CloseScript"))
   this.RegisterStartupScript("CloseScript",strScript);

Step 3:
Create the page that opens the dialog.  In the button or link that requires the modal dialog, setup the script that will open it for you.  I use the syntax "script defer" to allow the page to finish painting before opening the dialog.  "Defer" is not necessary and might not work in your situation, but it doesn't hurt to include it.  Make sure to include code that submits the form to allow processing of the dialog results.  By default, the form name is Form1, so the script is document.Form1.submit().  If you are creating a dialog the only displays information, then the document.Form1.submit(); script is not necessary.

string strScript = "<script defer>"+
   "var strReturn = window.showModalDialog('MyModalDialog.aspx?Parameter1=" + parameterVariable + "','','dialogWidth:520px;dialogHeight=600px');"+
   "document.Form1.submit();   </script>";

if (! this.IsClientScriptBlockRegistered("OpenMyDialog"))
  this.RegisterStartupScript("OpenMyDialog",strScript);

Of course, if the dialog doesn't required parameters then you don't need to set them up.  Set the dialogWidth and dialogHeight properties appropriately.

Step 4:
All that's left is to setup a way to determine what the user did inside the dialog.  Dialogs have many different uses, so this is where you can get creative.  Some dialogs may enter information into a database, some may be as simple as answering a yes or no question.  Still others may only be displaying information.  If I have a dialog that gathers data for entry into a database, I usually let the dialog handle the actual entry instead of passing the data back to the calling form.  This allows me to display any rule breaks or errors to the user without loosing track of what they were entering.  That way, they don't have to start all over with a blank form.  If the application is more complex, then you might need the main form to process the information before saving it to the database.

In almost all cases, the main form needs to know what the dialog has done.  So the approach I use works for nearly every situation.  I create a simple serializable object, DataTable, or DataSet (depending on the complexity of the dialog) to put into Session.  The main form normally seeds the variable with information.  The dialog can use the variable however is necessary.  In nearly every case, in the event that closes the dialog, the Session variable is modified and saved back into Session.  The calling form then uses it's Page_Load() event to check the variable and take appropriate action.

The dialog "accept" event code:

MyDialogObject DialogReturn = new MyDialogObject();
 ... save to database, fill DialogReturn properties, etc.
 
 Session[MYDIALOG] = DialogReturn;

 CloseWindow();  // Step 2 above

The main (calling) form code:

private void Page_Load(object sender, System.EventArgs e)
{
   if (! IsPostBack)
   {
      ... whatever ...
   }

   // If a dialog just closed, do whatever is necessary;
   if (Session[MYDIALOG] != null)
   {
      ProcessDialogInfo();
   }
}