Shift rows up/down in a table (server control)

My table has about 10 rows. Each row has "Up" and "Down" buttons.

When the user clicks on "Up" button, how do I shift the whole corresponding row above the preceding row?




table1.Rows[] is read-only. I cannot swap rows.




Thanks in advance.

Hey,

You are going to need to provide some more information than you currently have. For instance, how are the rows being generated?

Are you actually using an ASP.Net Table object, or are you using a Data Bound Control, if so, what?

Do you want this change to happen on the client side, or are you happy for this to happen on a post back to the server? Do you need to have these changes persisted to somewhere for later use?

Gary

I'm using ASP.Net Table object. The table is populated manually in the designer. It has exactly 10 rows and 3 columns. It doesn't matter whether the shifting takes place on the client side or the server side. When the user submits the form, the server needs to know the 'order' of the rows.

But I'd prefer if the shifting takes place at the server side


The problem finally boils down to this --> How do I shift two rows in a table?

This doesn't work because Tables.Rows[] is read-only

Code:

---

TableRow temp = Table1.Rows[0];
Table1.Rows[0] = Table1.Rows[1];
Table1.Rows[1] = temp;

---

This doesn't work as well

Code:

---

Table temptable = new Table();
temptable.Rows.Add(Table1.Rows[1]);
temptable.Rows.Add(Table1.Rows[0]);
Table1 = temptable;

---

Hey,

You still haven't mentioned whether this needs to be persisted at all? What exactly does this function serve? Can you provide more details? What context is this being used in?

One technique would be what is shown here:

http://aspdotnetcodebook.blogspot.co...idview-on.html

This uses a GridView rather than a Table, but then a GridView gets rendered to the client as a table.

Gary

It needs to be persisted.

The page basically generates some kind of report based on some input criteria. It generates SQL code on the fly and feeds it to the gridview. The input criteria go to 'WHERE' cause in the query.


The user can select which columns to display in the report and also in which order.



------------
http://i21.photobucket.com/albums/b2...ardy/table.jpg

So that's the purpose of the table.

It's not very clear from your postings how you are adding those table rows to the HTML markup -- whether they are in the ASPX or you are adding them dynamically.

In the situation, I would have defined a placeholder in ASPX and then added these table objects in the code at runtime. So when the user clicks any of the buttons, in the code behind I would iterate through the table rows and then do the manipulation based on what button was clicked of what row. Does that sound plausible?

Hey,

In post #3, you said that the rows of the table were created manually in the designer. This doesn't tie up with what you have just said.

Can you show some relevant markup and code behind? I think that will help us figure out what is going on, and what you are doing.

Gary

If the user clicks Up button, swap the contents of all cells of current row with the row above it. Same way when user clicks Down button, swap them with the row below it.

Perform the shift in the logic, not the presentation. So create a data structure that represents what you're presenting. A class with properties "ColumnName", "Position" and "IsDisplayed".

You then have a List(Of ColumnInfo) objects. You pass it to a method which takes that and generates the table rows based on the order of Position. You may actually want to consider a repeater because it can handle this generation and the buttons and the button click events too in its ItemCommand event.

Notice that you've now separated the presentation logic (repeater) from the business logic (list). You're now shifting items in the list rather than rows in the table.

I'd suggest you experiment with this concept first before applying it to your table. If it's too difficult, then go back to moving table rows :D


Pradeep: Awesome sig.

That will always be the best approach to take.
Because moving the HTML element (as suggested in my post) would require at least 2 iterations. But the databinding when implemented right may not need even one iteration.