I'm kind of new to ASP.Net, but have lots of ASP experience. I'm frustrated with things that could be done easily in classic ASP (though require manual coding) and I cannot figure out in ASP.Net 2.0.
For example, I'm using a gridview, and I want the ability for the user to be able to "select" multiple rows via a checkbox that exists in each row. Since I want to allow multiple row selection, I don't want to use the built in "select" ability of a gridview.
Also the requirement is to use a checkbox to indicate a row is selected, rather than changing background color.
I've added a checkbox to each row in the GridView, and bound it to a numeric field in the datasource. I did this because I noticed that if the numeric field had a value greater than 0 and is bound to a checkbox, it results in the checkbox being selected.
A value of 0 results in it being unselected. The numeric field will always return a 0 from in the SQL.
My hope was to be able to have the user check this checkbox, and the checkbox would maintain state as the user paged around through the resultset using the paging ability of the GridVIew.
Problem 1: The checkbox doesn't maintain state, each time a new page in the GridView is loaded, and then the user returns to the original "page", the state of the checkbox is lost.
I also wanted to have a commandbutton on the page (outside of GridView) that would then iterate through each "checked" item and perform some logic on it.
Problem 2: How does the GridView expose the underlying "model" so I can see what rows were checked?
For someone so new to ASP.NET, you're trying to do so much. Since you have experiences in the classic ASP, I'm sure you have a good feel for what can/should and cannot/should-not be done when developing web applications. What you are trying to implement is
a classic case of someone trying to implement a Windows-application-like feature into Web applications.
I can't tell you how to implement this (will take too long), but can give you some pointers.
First of all, you have to think of web pages as a mini-application. For example, when a page is requested, a mini-application gets invoked on the server that is responsible for generating the page about to be rendered. Once done, it closes -- meaning that
no values are persisted across each page request (i.e. postback). Given this behavior, you should realize that when moving to another page of your GridView, the "checked" values you've set for your CheckBox on the previous page will be lost, unless you do
some processing on the server to save those changes. The most obivious place to save these changes is your DB.
Now you're probably wondering how do I detect and save the changes? Well, this can be done via the RowCommand event of your GridView which gets called for all GridView's commands like Select/Edit/Delete command buttons as well as Paging and Sorting (Page and
Sort commandname, respectively). It's in this RowCommand event where you should save the changes to your DB by iterating through your GridView.Rows and retrieving the CheckBox state (along with your key value of the corresponding DB rows).
As you can see, this can be done, but requires quite a bit of understanding of ASP.NET and GridView features as well as DB-related funtionalities. For bits-and-pieces of information you'll need, you can probably search the forum (once they are done fixing
the indexing required to perform proper searches -- supposed to be done by this weekend). Once you understand them, it becomes easier.
One final note is that you may want to start looking into AJAX (especially the Atlas -- see the menu at top-right). It'll make your life as a developer easier when implementing Windows-like features. You'll also need to learn quite a bit, but once learned,
you'll never go back to traditional web development.
I don't see the need to use the RowCommand event. First of all I don't want to save the fact that I've
"checked" the row to the database, I just want a method for the user to select which rows they are intersted in, and then be able to view a list of records that only match their selections. I understand the response/request model, but I thought ASP.Net was
supposed to handle the binding for you, and the whole concept of the "viewstate" was developed to maintain state between requests.
What I describe is common in real estate websites that allow you to build a list of "favorite" houses our of your search results and then view that list of favorites. What I describe is far from unique for a web app to do. It is used in probably thousands
of real estate websites, travel websites, any website that can show you a list of items that match a search and allow you to narrow down that list to those you are most interested in.
Secondly, as I said this can be readily done in classic ASP, and also in JavaServerFaces (JSF) which I use also (though not for this project). JSF is more like ASP.Net than ASP, and it's binding seems lightyears ahead of what ASP.Net supports.
I thought the idea of databinding was to isolate the developer from having to manually bind the UI that the user sees with the underlying "model" (in this case, the result set).
I cannot imagine that the move from ASP to ASP.Net will be so crippling to the developer, especially when the competition (JSF) allows this to be done so very easily and cleanly.
Having said all that, I still don't understand why the checkbox's status isn't maintained when I navigate the pages of the GridView? I saw this type of problem happen in ASP.Net 1.0 when I did the DataBind() regardless of postback status. But the GridVIew
seems to autopopulate and doesn't need a call to BindData().
If you intend to simply read back the values of your CheckBox controls (in a GridView) for the current page, then it should be trivial. I don't think any other development tools allow ViewState persistence to multiple pages since they are not kept in memory
across postbacks (only the current page is). As for auto-databinding, it works only for one record at a time, not for multiple rows (for any data controls). Your original post seemed to imply wanting ViewState persistence for multiple pages.
I can say with 100% certainty that the JavaServerFaces framework supports maintaining the state of a checkbox in their "DataTable" (a UI component just like a GridView) as the user navigates through each page in the result set.
What is the point of binding an input control (such as a checkbox) to an item in the resultset if the binding is lost as the user goes to a different page in the resultset of the gridview?
I cannot imagine this huge deficiency exists in DotNet. I could readily to this manually in classic ASP (and have in other websites). I was hoping that the move to ASP.Net from ASP would open doors, not slam them shut. I though ASP.Net was supposed to
be a step forward, not a step back, from classic ASP.
Does everyone agree that if I put a checkbox in a row in a GridView, that there is no way to maintain state of that checkbox if the user navigates to a different page in the resultset? If so, I am going to have to use a different technology, may be even
classic ASP, just because it cannot accomplish this simple design UI goal.
Including a checkbox as part of a row in a GridView is not a "complicated" thing to expect to be supported, and it NOT a "windows app" type of functionality. As far as ViewSTate persistance accross multiple pages, I disagree. I am staying on the same "page"
(same ASPX), but am navigation through the resultsets in a GridView using it's built in paging functionality. Why shouldn't ViewState be able to maintain state within the page.
I'm afraid that I don't agree with your question. ASP.NET does not prevent you from using any classic ASP techniques, so if you can do this in ASP then you can do this in ASP.NET as well.
There are also quite a lot of standard ways that you could do this simple state management functionality in ASP.NET, including (but not limited to)
1. Using the Session object
2. Using the Profile API
3. Using your own Hidden Field,
4. Using ViewState
All of them might involve writing a few lines of code, I'm afraid, so it's not completely automatic.
I agree, putting a checkbox in a GridView is not complicated, might be considered Windows functionality, but is something that people would like to do. And yes, you can do it with ViewState.
So now that you've confirmed it is possible, I guess I am back to my original question: How can I have a checkbox on a row in a GridView and maintain state as the user clicks the "paging" links in the gridview.
Secondly how can I iterate through the rows in the resultset behind the gridview and see which rows have been checked. Out of the 4 methods you mentioned, which is the prefered approach and how would I go about implementing it?
I'm not familiar with JavaServerFaces, so I can't comment on it or compare it to ASP.NET. Nor am I defending ASP.NET if this feature you find so important isn't as well supported. You should choose the tool you're comfortable with. Having said that, I can
accomplish whatever the requirements through a bit of programming. If you're not comfortable with that and wish to choose/stick with a tool that does things automatically, then that is your choice. My experience has been that programming is an integral part
of any development tool. Different people expect different amount of built-in funtionalities and maybe I'm less demanding in that respect. As far as I'm concerned, ASP.NET (2.0, especially) is a great development tool with support for great development language
(VB.NET and C#). Perhaps one day you can appreciate where I'm coming from.
So now that you've confirmed it is possible, I guess I am back to my original question: How can I have a checkbox on a row in a GridView and maintain state as the user clicks the "paging" links in the gridview.
Secondly how can I iterate through the rows in the resultset behind the gridview and see which rows have been checked. Out of the 4 methods you mentioned, which is the prefered approach and how would I go about implementing it?
I'm a bit confused when it comes to "paging" you are referring to. You've said in one post that you are staying within the same page while on this post, you mention clicking on the "paging" links. If you're paging through your dataset bound to GridView, then
you will lose the viewstate of your checkbox controls unless you save it through one of the events (via programming). It may be the same "web-page," but it is a different page nonetheless.
Yes I am staying within the same ASPX, but navigating through the pages in the GridView. So it is the same page. This is exactly the condition that ViewState was designed to address.
When you fill in a WebForm, and click SUBMIT, but one of the fields fails validation, you don't lose the state of the other fields. Why should paging be any different? A request is sent to the server, the server returns the same page to the browser, and
state should be maintained.
Otherwise what is the point of a "bound" field if it loses state as soon as the page is submitted. Obviously you must be mistaken, it's the only thing that makes sense. In fact, I see that I can do "two way binding" when binding to a field. This indicates
to me that the data should be bound not only in the "dataset-to-ui" manner, but also in "ui-to-dataset" manner.
What I ask for is not complicated. It is trivial to accomplish in other frameworks. It seems unlikely that Microsoft is so far behind the curve on this one.
dtaylo75
Member
242 Points
66 Posts
GridView Checkbox maintaining state
Apr 02, 2006 03:48 PM|LINK
I'm kind of new to ASP.Net, but have lots of ASP experience. I'm frustrated with things that could be done easily in classic ASP (though require manual coding) and I cannot figure out in ASP.Net 2.0.
For example, I'm using a gridview, and I want the ability for the user to be able to "select" multiple rows via a checkbox that exists in each row. Since I want to allow multiple row selection, I don't want to use the built in "select" ability of a gridview. Also the requirement is to use a checkbox to indicate a row is selected, rather than changing background color.
I've added a checkbox to each row in the GridView, and bound it to a numeric field in the datasource. I did this because I noticed that if the numeric field had a value greater than 0 and is bound to a checkbox, it results in the checkbox being selected. A value of 0 results in it being unselected. The numeric field will always return a 0 from in the SQL.
My hope was to be able to have the user check this checkbox, and the checkbox would maintain state as the user paged around through the resultset using the paging ability of the GridVIew.
Problem 1: The checkbox doesn't maintain state, each time a new page in the GridView is loaded, and then the user returns to the original "page", the state of the checkbox is lost.
I also wanted to have a commandbutton on the page (outside of GridView) that would then iterate through each "checked" item and perform some logic on it.
Problem 2: How does the GridView expose the underlying "model" so I can see what rows were checked?
jcasp
Star
11540 Points
2286 Posts
Re: GridView Checkbox maintaining state
Apr 02, 2006 05:11 PM|LINK
I can't tell you how to implement this (will take too long), but can give you some pointers.
First of all, you have to think of web pages as a mini-application. For example, when a page is requested, a mini-application gets invoked on the server that is responsible for generating the page about to be rendered. Once done, it closes -- meaning that no values are persisted across each page request (i.e. postback). Given this behavior, you should realize that when moving to another page of your GridView, the "checked" values you've set for your CheckBox on the previous page will be lost, unless you do some processing on the server to save those changes. The most obivious place to save these changes is your DB.
Now you're probably wondering how do I detect and save the changes? Well, this can be done via the RowCommand event of your GridView which gets called for all GridView's commands like Select/Edit/Delete command buttons as well as Paging and Sorting (Page and Sort commandname, respectively). It's in this RowCommand event where you should save the changes to your DB by iterating through your GridView.Rows and retrieving the CheckBox state (along with your key value of the corresponding DB rows).
As you can see, this can be done, but requires quite a bit of understanding of ASP.NET and GridView features as well as DB-related funtionalities. For bits-and-pieces of information you'll need, you can probably search the forum (once they are done fixing the indexing required to perform proper searches -- supposed to be done by this weekend). Once you understand them, it becomes easier.
One final note is that you may want to start looking into AJAX (especially the Atlas -- see the menu at top-right). It'll make your life as a developer easier when implementing Windows-like features. You'll also need to learn quite a bit, but once learned, you'll never go back to traditional web development.
Good luck.
dtaylo75
Member
242 Points
66 Posts
Re: GridView Checkbox maintaining state
Apr 02, 2006 08:31 PM|LINK
I don't see the need to use the RowCommand event. First of all I don't want to save the fact that I've
"checked" the row to the database, I just want a method for the user to select which rows they are intersted in, and then be able to view a list of records that only match their selections. I understand the response/request model, but I thought ASP.Net was supposed to handle the binding for you, and the whole concept of the "viewstate" was developed to maintain state between requests.
What I describe is common in real estate websites that allow you to build a list of "favorite" houses our of your search results and then view that list of favorites. What I describe is far from unique for a web app to do. It is used in probably thousands of real estate websites, travel websites, any website that can show you a list of items that match a search and allow you to narrow down that list to those you are most interested in.
Secondly, as I said this can be readily done in classic ASP, and also in JavaServerFaces (JSF) which I use also (though not for this project). JSF is more like ASP.Net than ASP, and it's binding seems lightyears ahead of what ASP.Net supports.
I thought the idea of databinding was to isolate the developer from having to manually bind the UI that the user sees with the underlying "model" (in this case, the result set).
I cannot imagine that the move from ASP to ASP.Net will be so crippling to the developer, especially when the competition (JSF) allows this to be done so very easily and cleanly.
Having said all that, I still don't understand why the checkbox's status isn't maintained when I navigate the pages of the GridView? I saw this type of problem happen in ASP.Net 1.0 when I did the DataBind() regardless of postback status. But the GridVIew seems to autopopulate and doesn't need a call to BindData().
jcasp
Star
11540 Points
2286 Posts
Re: GridView Checkbox maintaining state
Apr 02, 2006 10:03 PM|LINK
dtaylo75
Member
242 Points
66 Posts
Re: GridView Checkbox maintaining state
Apr 02, 2006 11:39 PM|LINK
I can say with 100% certainty that the JavaServerFaces framework supports maintaining the state of a checkbox in their "DataTable" (a UI component just like a GridView) as the user navigates through each page in the result set.
What is the point of binding an input control (such as a checkbox) to an item in the resultset if the binding is lost as the user goes to a different page in the resultset of the gridview?
I cannot imagine this huge deficiency exists in DotNet. I could readily to this manually in classic ASP (and have in other websites). I was hoping that the move to ASP.Net from ASP would open doors, not slam them shut. I though ASP.Net was supposed to be a step forward, not a step back, from classic ASP.
Does everyone agree that if I put a checkbox in a row in a GridView, that there is no way to maintain state of that checkbox if the user navigates to a different page in the resultset? If so, I am going to have to use a different technology, may be even classic ASP, just because it cannot accomplish this simple design UI goal.
Including a checkbox as part of a row in a GridView is not a "complicated" thing to expect to be supported, and it NOT a "windows app" type of functionality. As far as ViewSTate persistance accross multiple pages, I disagree. I am staying on the same "page" (same ASPX), but am navigation through the resultsets in a GridView using it's built in paging functionality. Why shouldn't ViewState be able to maintain state within the page.
DMW
All-Star
15943 Points
2353 Posts
Re: GridView Checkbox maintaining state
Apr 03, 2006 12:38 AM|LINK
I'm afraid that I don't agree with your question. ASP.NET does not prevent you from using any classic ASP techniques, so if you can do this in ASP then you can do this in ASP.NET as well.
There are also quite a lot of standard ways that you could do this simple state management functionality in ASP.NET, including (but not limited to)
1. Using the Session object
2. Using the Profile API
3. Using your own Hidden Field,
4. Using ViewState
All of them might involve writing a few lines of code, I'm afraid, so it's not completely automatic.
I agree, putting a checkbox in a GridView is not complicated, might be considered Windows functionality, but is something that people would like to do. And yes, you can do it with ViewState.
Dave
dtaylo75
Member
242 Points
66 Posts
Re: GridView Checkbox maintaining state
Apr 03, 2006 12:44 AM|LINK
So now that you've confirmed it is possible, I guess I am back to my original question: How can I have a checkbox on a row in a GridView and maintain state as the user clicks the "paging" links in the gridview.
Secondly how can I iterate through the rows in the resultset behind the gridview and see which rows have been checked. Out of the 4 methods you mentioned, which is the prefered approach and how would I go about implementing it?
jcasp
Star
11540 Points
2286 Posts
Re: GridView Checkbox maintaining state
Apr 03, 2006 01:21 AM|LINK
jcasp
Star
11540 Points
2286 Posts
Re: GridView Checkbox maintaining state
Apr 03, 2006 01:26 AM|LINK
I'm a bit confused when it comes to "paging" you are referring to. You've said in one post that you are staying within the same page while on this post, you mention clicking on the "paging" links. If you're paging through your dataset bound to GridView, then you will lose the viewstate of your checkbox controls unless you save it through one of the events (via programming). It may be the same "web-page," but it is a different page nonetheless.
dtaylo75
Member
242 Points
66 Posts
Re: GridView Checkbox maintaining state
Apr 03, 2006 01:58 AM|LINK
Yes I am staying within the same ASPX, but navigating through the pages in the GridView. So it is the same page. This is exactly the condition that ViewState was designed to address.
When you fill in a WebForm, and click SUBMIT, but one of the fields fails validation, you don't lose the state of the other fields. Why should paging be any different? A request is sent to the server, the server returns the same page to the browser, and state should be maintained.
Otherwise what is the point of a "bound" field if it loses state as soon as the page is submitted. Obviously you must be mistaken, it's the only thing that makes sense. In fact, I see that I can do "two way binding" when binding to a field. This indicates to me that the data should be bound not only in the "dataset-to-ui" manner, but also in "ui-to-dataset" manner.
What I ask for is not complicated. It is trivial to accomplish in other frameworks. It seems unlikely that Microsoft is so far behind the curve on this one.
Can anybody restore my faith in ASP.Net here?