DropDownList without Autopostback

Question

I need a DropDownlist which can cause SelectedIndexChanged event but do not do post back(do not need page_load event when ddl index changed).

After looking into solutions in Stack here is my code:

  <asp:UpdatePanel runat="server">

            <ContentTemplate>
                <asp:DropDownList ID="a" runat="server" OnSelectedIndexChanged="a_SelectedIndexChanged">
                    <asp:ListItem Text="a"></asp:ListItem>
                    <asp:ListItem Text="b"></asp:ListItem>
                </asp:DropDownList>

            </ContentTemplate>
            <Triggers>
                <asp:AsyncPostBackTrigger ControlID="a" EventName="SelectedIndexChanged" />
            </Triggers>
        </asp:UpdatePanel>

and C# code:

public partial class TestApp : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        txtDate.Text = DateTime.Now.ToString("yyyy-MM-dd");
    }

    protected void a_SelectedIndexChanged(object sender, EventArgs e)
    {
        int a = 1;
    }
}

But the break point in put in a_SelectedIndexChanged never gets fired. What could be the issue here?

As you see the above is an accpeted answer on stack, then how its not workining: How DropDownList's SelectedIndexChanged() works without PostBack?

Edit: While the below answer correctly explains that page_load should fire all the times. I still want to know why SelectedIndexChanged never gets fired. So what EventName="SelectedIndexChanged" in the Trigger does?

Answer 1

While a update panel (UP for this post) will "ajax" up, and ONLY post-back that part of the page. (and code behind for that UP can only update controls in that UP?).

The page load even will ALWAYS fire each time.

In fact, page load fires for any button click, post-back, changed event or anything at all.

Thus, as a STANDARD design pattern?

If your page load event loads up a drop down list, listbox, gridview etc.?

Then you ONLY want that code to run on the "real" first page load.

As a result, the last 200+ web pages I have built?

They have this:

    protected void Page_Load(object sender, EventArgs e)
    {
        if (!IsPostBack)
            LoadData();
    }

    void LoadData()
    {
        Repeater1.DataSource = General.MyRst("SELECT * from tblHotelsA");
        Repeater1.DataBind();

    }

So, in above example, I am loading up a "repeater" with some data.

However, REGARDLESS if you using a UP or not?

Your page load code, first time MUST quite much do the above.

If you don't do the above, then simple code that say loads up a dropdown list (combo box) will fire each and every time.

If then if you select a combo box value, then say click a button on the page?

the page load fires first, AND THEN your button code. But, if page load re-loads the combo box, then you lose your selection.

So, update panel or not?

Your page load event fires each and every time - including when you use that UP.

So, even without a UP, it stands to reason you can't really even build a working web page if you page load event EVERY time loads up data and controls, since then any changes to such controls will be "blowen" out, and over written each time.

So, while the UP results in what "appears" to not be a post-back?

it is in fact what we call a partial post-back. And the standard page life cycle does occur, but ONLY the bits and parts in the UP are posted back to the server, and in that case, ,then the code behind of course can only change/modify the controls inside of that UP (quite much the whole idea).

So, while the UP will "eliminate" the browser spinner, and while it KEEP your current scroll position on the page?

Make no mistake here - that partial post-back is in fact a page post-back, but just a smaller one, and one that looks to the user that no post-back occurred.

so, it is fine and dandy to have auto-post back for that dropdown list. (and you do NOT even require a trigger, and I suggest you remove the trigger, and put back in the auto post-back.

So, the UP does not "eliminate" the post-back, but hides this from the end user, and for the most part it can be rather nice, quick, and of course will not refresh the whole page. But, page load still fires each and every time.

So, for your code to work correctly, and only fire on the VERY first time, and what amounts to the "real" first page load?

Then your code has to be this:

    protected void Page_Load(object sender, EventArgs e)
    {
        if (!IsPostBack)
        {
            txtDate.Text = DateTime.Now.ToString("yyyy-MM-dd");
        }
    }

Now, if you really don't want any kind of post back?

Then you have to start writing some JavaScript, and start making ajax calls to some web methods.

Now, a ajax call certainly is "less" of a post-back then a UP, which in turn is less of a full page post-back.

If you absolute have a "poor" page design in which a UP can't be used, then yes, you have to start writing and adding client side js code, and thus you can setup a ajax call, and no page post-back will occur. it is quite rare that a UP can't be used, but ajax calls are better, but they also take significantly more time to setup, write and adopt.

However, keep in mind that a ajax call to server code does not have any use of controls on the page. So, you have to return values, and then have your js code update the controls on the page.

So, if a UP can suffice, then that's the least effort. The fantastic part is you don't have to write up and wire up a whole bunch of JavaScript code in place of using that UP.

For sure, a ajax call is best, but that takes more code, more time, and has more moving parts (and requires JavaScript skills on your part). Often this extra effort and time (cost) can't be justified to adopt ajax calls for the page, so a UP is a good middle ground. it is somewhat of a compromise compared to ajax calls, but it boatloads of less work, and thus often a great choice cost and time wise. In other words, in most cases a UP is "good enough".