Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>There's a difference in the drop-down lists for your two cases, which I think is probably the cause of this. For Insert, you have AppendDataBoundItems="true", while for the Update form above it, this flag is not set (and it defaults to false). What that means in terms of the submitting form is that, for the Insert form, when it's rebinding it appends the items to the current list instead of clearing them; but for the Update form, because it's not set to append, it will clear the items and THEN binds them -- so the Binding is happening in both cases, but in the case of the Update form, it's clearing the items when that happens and giving you blank data.</p> <p>Instead of just rejecting the filtering on Postback, which causes your form to fail eventually, I would instead filter based on the control that CAUSED the Postback. At the top of the function you can capture the control ID that caused the postback, and then you can filter only when it isn't a postback coming from the buttons that are triggering the data storage step. If that's in place, I believe you should be able to do away with the AppendDataBoundItems flags altogether.</p> <p>A code snippet update of what I mean:</p> <pre><code>string initControl = Request.Form["__EVENTTARGET"]; if (!IsPostBack || (initControl != "btnInsert" &amp;&amp; initControl != "btnUpdate") { // code here } </code></pre> <p>What this does is expand the check for PostBack so that the conditions are allowed EITHER if not a post back (which you tested previously), but critically, it'll also allow the lists to update if the form IS posted back, so long as the control posting back isn't one that is triggering an event dependent on the contents of those bound elements. That should mean that you avoid the problem of it only working for the first page load.</p> <p>Additionally, if you need the control to bind regardless, you could add a global boolean variable to the script; set it to False by default, and then set it to True if the above condition is not met (i.e., if you're preventing the binding). Then you can check that boolean value in the Page_PreRender function, and if it's set to true, you can perform a late binding of the control at that step (which will only fire after the Insert/Update events have already processed, so any binding at that point will no longer affect the result of the form processing).</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload