This row already belongs to another table

It does, that’s the whole point - I’m trying to copy a row from one datatable to another.

Funnily, we can’t just use the (dt is DataTable) “dt.Rows.Add(<datarow>)” method; probably because the datarow contains identifying information relevant to the original datatable - so we have to use “dt.ImportRow(<datarow>)” instead.

Just remember that kids, you can’t just take things that aren’t yours and pretend they are, you have to import them ;)

One of the most elementary mistakes that I have seen fellow coders make, in .NET anyway, is trying to loop through data within objects using a count of rows/columns. The row number of the datarows does not start at the same number as the start of the loop through a reflection of .Count.

If you are looping through a set of datarows it will start at 0, as objects are zero-based indexed.

If you count the number of datarows then want to loop through them all, it will count them as you and I would, starting from 1.

So, if you are looping through a set of datarows and want to get through them all, from the beginning to the number of rows you must loop from 0 to the number of rows minus 1 (- 1) or else you will get an ArgumentOutOfRangeException because it tries to find columns 1, 2, 3 in the dataset instead of 0, 1, 2.

Here’s some delightful error handling…

Catch oor As ArgumentOutOfRangeException

'Try going back one? *shrug*

i = i -1

Yup, if the loop has gone too far but still has stuff to process, just … go back and do the last one again :)

My favourite mistake, databinding too early.

If there is one mistake I make almost every single time when working with webforms it is this one, databinding controls during the OnLoad event. This is particularly perilous for DropDownLists and RadioButtonLists and I’ll tell you why …

OnLoad is fired very early on in the ASP.NET page lifecycle and what this does is wipe out any selections you made before postback because the control has been cleared and then re-populated, clearning SelectedValue, SelectedItem etc.

I’ve seen many different ways that people databind controls to overcome this, but the plain, simple and easiest way is to just databind later, after you have dealt with the SelectedValue or SelectedItem properties. Personally, I databind during PreRender.

Injecting Javascript into webforms from code-behind

AJAX has become very very popular and the resurgence of javascript has been unprecendented, spurred on by libraries like jQuery and Mootools, we can now do partial-page postbacks, get data and fire events asynchronously easier than ever thought possible.

In ASP.NET we have the luxury of having an AJAX framework built in from v3.5 onwards that includes some pretty powerful tools, the best of which is the UpdatePanel. The UpdatePanel allows us to trigger partial-page postbacks and hit methods and classes in the code-behind with little effort to wire-up the event.

This can be built upon by using an UpdatePanel in conjunction with jQuery through the ScriptManager object. ScriptManager will inject javascript into a page asynchronously and then let it do its stuff.

What this means, in laymans terms, is that you can hit a button, return some data and run some javascript all without a postback.

The simplest example of ScriptManager usage is this;

ScriptManager.RegisterClientScriptBlock(Page, GetType(), “Load”, “Load();”, true);

ScriptManager.RegisterClientScriptBlock(Page, GetType, “Load”, “Load();”, true

What this does is, on a partial page postback, adds this to the page;

<script type=”text/javascript”>

So executing a javascript function called  that has already been included in the page but been laying dormant until now, and this can do anything you want; run some jQuery to pop-up a modal window, change the colour of some text or whatever, or perform some validation, the possibilities are endless.

Want to inject javascript into a webform from code-behind that hasn’t been fired asynchronously? Use the ClientScriptManager object instead of ScriptManager. ClientScriptManager runs at the beginning of a a full-page postback.

Viewstate is your friend

Persisting the state of DropDownLists in ASP.NET is simpler than you think.
A lot of people will go the way of storing the SelectedIndex in a Session variable on postback then retrieving it and setting the SelectedIndex again on Load - but this is all unnecessary in most circumstances.

If you simply want to set the SelectedValue to be what it was before a PostBack, simply use the EnableViewState options at both Page and Control level.

EnableViewState=”true” in your <@Page attribute at the top of the web form and EnableViewState=”true” in the <ASP:DropDownList control.

And that’s it. No faffing around in the code-behind, trying to grab the SelectedIndex before it gets wiped out by the Page_Load or setting it after the DataBind. Simple as.