Reload Post data in onClick in asp.net

asp.netcontrolsdynamicpostback

Code is simplified to make it clearer.

The description

I'm writing a custom control that uses Controls.Add() to add all of the sub control it wants.

Say for example my control is called "lots_of_text_boxes" and I add a minimum number of text boxes and provide a button (Controls.Add(button)) that says "add new text box".

The control renders nicely. I click the button, the OnLoad(EventArgs e) recreates the sub controls and asp.net's magic find all my posted data and fills in the text boxes so I can read them.

btnAddNew_Click(object sender, EventArgs e) gets called to add a new textbox.

At first I tried Controls.Add(textbox) but this puts the text box at the bottom under the add button.

I could remove the button, add the text box and re add the button but I don't want to do this because it is not simple in the real case (lots of related buttons and controls intertwined).

What I want to do:
Number_of_Textboxes_to_show++;
Controls.Clear();
OnLoad(new EventArgs());

this wipes the control to start over and recreates it with one new ones.

The problem

because the postdata was already loaded the page is redrawn but all the data in the fields was lost.
I really want a function "LoadPostData()" that goes through all the sub controls and reloads their post data.

it makes sense to me that the post data is still in memory (I hope) and all the controls on pass 2 have the same unique ID's as they did on pass 1 (and on the previous form that was posted).

Has anyone see anything like this?

Best Answer

It sounds like the problem is just simple control placement. If the controls were being added to the place that you wanted (above the button), there would be no need to wipe the form and rebuild it, correct?

I would suggest adding a few Panel or Placeholder controls to your user control to define the layout of it. That way, your textboxes could be added to the Panel instead of the overall usercontrol, and your layout would be preserved and the controls would be where you want them.

Website:

The Web Site project is compiled on the fly. You end up with a lot more DLL files, which can be a pain. It also gives problems when you have pages or controls in one directory that need to reference pages and controls in another directory since the other directory may not be compiled into the code yet. Another problem can be in publishing.

If Visual Studio isn't told to re-use the same names constantly, it will come up with new names for the DLL files generated by pages all the time. That can lead to having several close copies of DLL files containing the same class name, which will generate plenty of errors. The Web Site project was introduced with Visual Studio 2005, but it has turned out not to be popular.

Web Application:

The Web Application Project was created as an add-in and now exists as part of SP 1 for Visual Studio 2005. The main differences are the Web Application Project was designed to work similarly to the Web projects that shipped with Visual Studio 2003. It will compile the application into a single DLL file at build time. To update the project, it must be recompiled and the DLL file published for changes to occur.

Another nice feature of the Web Application project is it's much easier to exclude files from the project view. In the Web Site project, each file that you exclude is renamed with an excluded keyword in the filename. In the Web Application Project, the project just keeps track of which files to include/exclude from the project view without renaming them, making things much tidier.

Reference

The article ASP.NET 2.0 - Web Site vs Web Application project also gives reasons on why to use one and not the other. Here is an excerpt of it:

You need to migrate large Visual Studio .NET 2003 applications to VS 2005? use the Web Application project.

You want to open and edit any directory as a Web project without creating a project file? use Web Site project.

You need to add pre-build and post-build steps during compilation? use Web Application project.

You need to build a Web application using multiple Web projects? use the Web Application project.

You want to generate one assembly for each page? use the Web Site project.

You prefer dynamic compilation and working on pages without building entire site on each page view? use Web Site project.

You prefer single-page code model to code-behind model? use Web Site project.

Web Application Projects versus Web Site Projects (MSDN) explains the differences between the web site and web application projects. Also, it discusses the configuration to be made in Visual Studio.

ASP.NET custom control: when is LoadPostData() called

I am a little late jumping in on this but, just for future reference, here is how I accomplished something similar…

My control is a tree that uses templates for the nodes. The issue where I was dealing with this was how to capture the client side changes to the expanded/collapsed state of the nodes. What ended up working was:

In CreateChildControls add the hidden field to the controls collection of my root control.

protected override int CreateChildControls(IEnumerable dataSource, bool dataBinding)
{
    ...
    _cdExpanded = new HiddenField();
    _cdExpanded.ID = "cdExpanded";
    this.Controls.Add(_cdExpanded);
    ...
}

In OnInit call

protected override void OnInit(EventArgs e)
{
    ...
    Page.RegisterRequiresPostBack(this);
    ...
}

In LoadPostData look for a value in the post collection that matches the UniqueID (not ClientID) of the hidden field:

public bool LoadPostData(string postDataKey, System.Collections.Specialized.NameValueCollection postCollection)
{
    ...
    string cdExpanded = postCollection[_cdExpanded.UniqueID];
    ...
}

Within the classes for the individual nodes I have code which populates the onclick events of my toggle buttons with a call to a JavaScript function which takes the ID of the base control and the individual nodes as arguments.

    string ToggleScript
    {
        get
        {
            return "ToggleNode('" + this.ClientID + "', '" + _TreeRoot.ClientID + "');";
        }
    }
    protected override void Render(HtmlTextWriter writer)
    {
        ...
        if (this.HasChildren)
        {
            writer.AddAttribute("onclick", ToggleScript);
        }
        ...
    }

This makes it so that finding the hidden field is fairly easy via getElementById:

function ToggleNode(nodeID, treeID) {
var cdExpanded = document.getElementById(treeID + "_cdExpanded");
...
}

The JavaScript then modifies the value of the hidden field as needed for the event that occurred. When we get back to the server I am able to parse out the contents of this field and modify the control state as necessary before it gets rendered again. (Note: I actually use 3 hidden fields for tracking different events but the concept is the same)

Hope this helps others in the future…

Best Answer

Related Solutions

.net – ASP.NET Web Site or ASP.NET Web Application

Website:

Web Application:

ASP.NET custom control: when is LoadPostData() called

Related Topic