Viewstate and Postback

Published 1/12/2006 by Henry in ASP.NET | C#
Tags: ,

While working on an ASP.NET project I am building kind of a wizard. There will be dynamically created input controls like textboxes, dropdownlists, radiolists etc. So I built controls that contain validation etc.
But between postbacks, while dynamically creating "new" wizardforms (different controls than on the previous one) the viewstate cannot handle this anymore.

The following information is available:

Stacktrace starts with:
[InvalidCastException: Specified cast is not valid.]
   System.Web.UI.StateBag.LoadViewState(Object state)
   etc, etc.

So on a page that contains controls, when dynamically creating controls on this page after a postback there can arise a problem with the viewstate. I consider this to be a bug, but Microsoft explains the reason why in another manner.

After asking Uncle Google I learnt the following from the MSDN website
Dynamic controls and ViewState

MSDN website:
In most scenarios, this view state processing model works fine. Typically, you add dynamic controls to the end of a container's collection of controls. The view state information stored for the dynamic controls is therefore extra information at the end of the view state structure for the appropriate container, and the page can ignore it until after the controls are created.
However, view state information about dynamically created controls can be a problem in two scenarios:

If you insert dynamic controls between existing controls.
If you insert controls dynamically and then reinsert them during a round trip, but with different values.
If you insert dynamic controls between existing controls, the dynamic control's view state information is inserted into the corresponding location of the view state structure. When the page is posted and the view state is loaded, the dynamic control does not yet exist; therefore, the extra information in view state does not correspond to the right control. The result is usually an error indicating an invalid cast.

In other words, sorry we cannot do this with ASP.NET.
I tried to sit back and think the problem over:

After postbacks I cannot rebuild the page with new controls.

Solution:
Store necessary state info in Session and use Response.Redirect(url); to redirect the aspx page to itself.

Microsoft does not even mention this in the article.

Henry Cordes
My thoughts exactly... 


Factory Pattern

Published 11/10/2005 by Henry in C# | Patterns
Tags: ,

The challenge:
We got a lot of classes derived from one baseclass. Like a TableRow with controls in it.
Every control got another control in the third row, like:

  • A Textbox
  • A DropdownListBox 
  • A RadioButtonList
  • Multiple Textboxes and a Dropdownlist (Date)
  • Etc.

In our client (A Webb App) we do not want to be bothered with which control we have to instantiate. We want to instantiate and get the right kind of object returned.
For this kind of scenario we can use the Factory Pattern.

A Factory Pattern returns an instance of one of the several classes depending upon the parameters passed to the shared/non-shared factory method. Typically, all these classes are inherited from a common parent class.
Each of them has common methods. But each of them has their own optimization task operation on data. For simplicity I decided to give an example that is more simple than the real life implementation I described above.
I will use a very simple example.

We got an abstract Employee class (must be inherited), which will act as our base class.
The Employee class has two properties:

  • Name (string)
  • Salary (double)

We derive from the Employee class two classes:

  • Developer
  • Manager

Because we do not want the hassle to instantiate another class everytime we want to create a developer instance, or a Manager instance and because there will be more Employee derived objects in the future (Secretary, Architect, etc.), we create a Factory class that does the job for us.
We call it the EmployeeFactory. 

UMLFactory.jpg

 Here is the code for the Employee class, with the derived classes:

   1:  using System;
   2:  namespace FactoryExample
   3:  {
   4:      public abstract class Employee
   5:      {
   6:          #region Private Members
   7:          private string m_Name = string.Empty;
   8:          private double m_Salary = 0;
   9:          #endregion
  10:          #region Public Properties
  11:          public string Name
  12:          {
  13:              get { return m_Name; }
  14:              set { m_Name = value; }
  15:          }
  16:          public double Salary
  17:          {
  18:              get { return m_Salary; }
  19:              set { m_Salary = value; }
  20:          }
  21:          #endregion
  22:      }
  23:   
  24:      public class Developer:  Employee
  25:      {
  26:          public Developer()
  27:          {
  28:              Name = "John Refactorer";
  29:              Salary = 2000;
  30:          }
  31:      }
  32:   
  33:      public class Manager: Employee
  34:      {
  35:          public Manager()
  36:          {
  37:              Name = "Peter PeopleManager";
  38:              Salary = 5000;
  39:          }
  40:      }
  41:  }

Next we have the Factory:

   1:  using System;
   2:  namespace FactoryExample
   3:  {
   4:      public class EmployeeFactory
   5:      {
   6:          public Employee CreateEmployee(int employeeKind)
   7:          {
   8:              Employee EmployeeObject;
   9:              switch (employeeKind)
  10:              {
  11:                  case 0:
  12:                      EmployeeObject = new Developer();
  13:                      break;
  14:                  case 1:
  15:                      EmployeeObject = new Manager();
  16:                      break;
  17:                  default:
  18:                      EmployeeObject = new Developer();
  19:                      break;
  20:              }
  21:              return EmployeeObject;
  22:          }
  23:      }
  24:  }

And last but not least the console app that calls the factory to instantiate the Developer and manager objects.

   1:  using System.Collections;
   2:  using System.Text;
   3:  namespace FactoryExample
   4:  {
   5:      class Program
   6:      {
   7:          static void Main(string[] args)
   8:          {
   9:              EmployeeFactory EmpFactory = new EmployeeFactory();
  10:              Employee emp;
  11:              for (int i = 0; i < 2; i++)
  12:              {
  13:                  emp = EmpFactory.CreateEmployee(i);
  14:                  Console.WriteLine("{0} - ({1}) Name: {2} Salary: {3}",
  15:                                      i,
  16:                                      emp.GetType().Name,
  17:                                      emp.Name,
  18:                                      emp.Salary);
  19:                  emp = null;
  20:              }
  21:              Console.Read();
  22:          }
  23:      }
  24:  }

When we run this code the output in the console looks like this:

 Console_fact.gif

I hope you get the idea, I have some real use for this pattern in the situaton described at the beginning of this post.

Henry Cordes
My thoughts exactly...


Load document in iframe dynamically

Published 11/3/2005 by Henry in ASP.NET | C#
Tags: ,

Supose you need to show an xml, html or aspx document inside an ASP.NET page. So you actually want to embed another page or document inside the original page. You want to load a document in an iframe dynamically from the server-side.
What you really need is an iFrame server control. However an iFrame is an html control and it's properties are not directly available at the server side (in the codebehind). So we need a way to access the 'src' property of the iFrame directly. Inside the iFrame's tag in the html of the aspx page we set the 'runat' attribute with the 'server' value.

   1:  <iframe id ="MyIframe" runat ="server"> 
   2:  </iframe> 

In the aspx.cs (codebehind) file we declare a System.Web.UI.HtmlGenericControl and name it (the name does not have to be the same as in the html page, but I think it is good practice to do so).

   1:  protected System.Web.UI.HtmlControls.HtmlGenericControl MyIframe;

We create a method we can call in order to load a document in our iFrame by using the FindControl method of the System.Web.UI.Page and typecast it This way we can acces all properties of the HtmlControl through the Attributes property. The "MyIframe" referred in Find Control is the ID as declared in the ASPX Page.

   1:  private void LoadDocumentInIFrame(string url)
   2:  { 
   3:      HtmlControl MyIframe = (HtmlControl)this.FindControl("MyIframe"); 
   4:      MyIframe.Attributes["width"] = "100%"; 
   5:      MyIframe.Attributes["height"] = "400px"; 
   6:      MyIframe.Attributes["src"] = url; 
   7:  }
   8:   
   9:   
  10:  // Example that calls the method
  11:  LoadDocumentInIFrame("http://www.google.com")


This way we can load a document in an iframe dynamically from server-side.
With the FindControl() we can get a reference to the HtmlGenericControl object and access the properties of it. As you will understand this is not limited only to the iFrame, but can be used for more 'HTML' controls.

Henry Cordes
My thoughts exactly...