Don't start trying combinations of suggestions, we all gave you different suggestions. The code you have above is setting the .Selected property of a CheckboxList (which is a bool) to a variable called "isSelected" which is declared as a CheckBoxList. That
is why you are getting a conversion bool to CheckBoxList error. You got a little mixed up here.Take a breather and look at what you are trying to accomplish. As I understand it, you are trying to find out if all checkboxes within a given list are checked.
Here are your steps:
Attempt to get a reference to a CheckBoxList
if that reference is not null, iterate through each item in the CheckBoxList
iterating through a CheckBoxList's .Items collection will return ListItem classes, which have a .Selected property
maintain a boolean throughout this iteration
Act appropriately to the final value of the boolean
bool allSelected = true;
//1.
CheckBoxList cbl = ((CheckBoxList)row.FindControl("CheckBoxList1"));
//2.
if(cbl != null)
{
//3.
foreach(ListItem li in cbl.Items)
{
if(!li.Selected)
{
//4.
allSelected = false;
}
}
}
//5.
//now you can test against allSelected
I still think the break; method given to you earlier might be more elegant, but for now, just try my suggestion because it is less confusing and see if it works. If it doesn't, explain what isn't working and we can examine further. It is possible that
we are failing on step 1, which makes the rest of this irrelevant, but atleast we won't be trying to st a CheckBoxList reference equal to true or false. We can polish it all off with better code after we can get some semblence of functionality.
"Dream as if you'll live forever, live as if you'll die today." --James Dean
No sweat. It's easy to get lost when you get different suggestions. Whenever you find yourself overwhelmed by something in the future, try breaking what you'd like to accomplish down into more bite-sized chunks. Then tackle each chunk at a time. It also
helps later if you have to debug it because you can go through each step and find where the break is occuring.
"Dream as if you'll live forever, live as if you'll die today." --James Dean
I don't want to confuse things, this is just my 2c worth.
I think that if a CheckBoxList item called CheckBoxList1 is not present in the row then you have a programming error. The correct thing to do in that case is to throw an exception. Returning allSelected = true in the case of a programming error and giving
no indication of any error is asking for trouble. I would code this scenario as
Indeed, mine was more a brute force method with the intent of polishing after we got to a concensus about where his confusion might have rested. Yours is a pretty elegant solution but, doesn't it still throw a null pointer exception if CheckboxList1 doesn't
exist? Granted, it could still be caught, but if, for instance, the CheckBoxList in question is dynamically generated, then null may not be an application breaking scenario as much as it may be an acceptable execution path. To support that you'd need to
surround this single line in a try-catch block to account for that possibility and allow execution to the following lines of code.
"Dream as if you'll live forever, live as if you'll die today." --James Dean
My main point was that if a NullRefernceException was to be generated then it is a good thing. It shows a programming error of some form. Perhaps the page was modified but the code behind was not or some dynamic control generation code has performed incorrectly.
In whatever case it is truely exceptional and I would want to 'fail fast' so that I know where the problem is.
Personal opinion - I would not want try/catch around this, I want to fail and fix the coding error that the Exception repesents. There is nothing tha anyone, except the programmer, could do about the problem. Certainly, I don't want to assume success and
hide the issue.
I don't disagree, but I still come across instances where null pointers are legitimate (albeit rare) execution paths. Perhaps in an AJAX enviornment where input from the user is used to make deductions on the server. I don't think that is necessarily the
case here, but it is an interesting point none-the-less. My point is, we don't truly know where this string "CheckboxList1" is coming from, and we cannot always trust the source. To have the application fail in such a manner looks to users as if it were
broken when it might otherwise be more appropraite to degrade gracefully.
"Dream as if you'll live forever, live as if you'll die today." --James Dean
artvindustri...
Member
14 Points
52 Posts
Re: CheckBoxList Returning Check
Jan 23, 2013 11:07 PM|LINK
I guesss Ive tried all combinations and variations of the above. Still no luck.
for (int i = 0; i < GridView1.Rows.Count; i++) { GridViewRow row = GridView1.Rows[i]; CheckBoxList isSelected = ((CheckBoxList)row.FindControl("CheckBoxList1")).Selected; //Selected doesn't exist. if (isSelected) { Response.Write("Its Checked"); return false; } Response.Write("Not Check"); }This says that it cannot convert type CheckBoxList to bool.
This was suggested to me:
int checkedCount = 0; foreach (ListItem item in CheckBoxList1.Items) { checkedCount += item.Selected ? 1 : 0; } if (checkedCount == CheckBoxList1.Items.Count) { //all checked } else if (checkedCount == 0) { //none checked }However, because the CheckBoxList1 is in the TemplateField, it doesn't qualify the reference.
AceCorban
Star
12358 Points
2274 Posts
Re: CheckBoxList Returning Check
Jan 23, 2013 11:35 PM|LINK
Don't start trying combinations of suggestions, we all gave you different suggestions. The code you have above is setting the .Selected property of a CheckboxList (which is a bool) to a variable called "isSelected" which is declared as a CheckBoxList. That is why you are getting a conversion bool to CheckBoxList error. You got a little mixed up here.Take a breather and look at what you are trying to accomplish. As I understand it, you are trying to find out if all checkboxes within a given list are checked. Here are your steps:
bool allSelected = true; //1. CheckBoxList cbl = ((CheckBoxList)row.FindControl("CheckBoxList1")); //2. if(cbl != null) { //3. foreach(ListItem li in cbl.Items) { if(!li.Selected) { //4. allSelected = false; } } } //5. //now you can test against allSelectedI still think the break; method given to you earlier might be more elegant, but for now, just try my suggestion because it is less confusing and see if it works. If it doesn't, explain what isn't working and we can examine further. It is possible that we are failing on step 1, which makes the rest of this irrelevant, but atleast we won't be trying to st a CheckBoxList reference equal to true or false. We can polish it all off with better code after we can get some semblence of functionality.
artvindustri...
Member
14 Points
52 Posts
Re: CheckBoxList Returning Check
Jan 23, 2013 11:50 PM|LINK
Ace,
Thank you for the suggestion. Im new and get overwhelmed with simple things sometimes. I really appreciate the breakdown
of what is trying to be accomplished. I will iterate through those steps.
artvindustri...
Member
14 Points
52 Posts
Re: CheckBoxList Returning Check
Jan 23, 2013 11:51 PM|LINK
Thanks Rion!
AceCorban
Star
12358 Points
2274 Posts
Re: CheckBoxList Returning Check
Jan 24, 2013 12:01 AM|LINK
No sweat. It's easy to get lost when you get different suggestions. Whenever you find yourself overwhelmed by something in the future, try breaking what you'd like to accomplish down into more bite-sized chunks. Then tackle each chunk at a time. It also helps later if you have to debug it because you can go through each step and find where the break is occuring.
Paul Linton
Star
13431 Points
2535 Posts
Re: CheckBoxList Returning Check
Jan 24, 2013 04:43 AM|LINK
I don't want to confuse things, this is just my 2c worth.
I think that if a CheckBoxList item called CheckBoxList1 is not present in the row then you have a programming error. The correct thing to do in that case is to throw an exception. Returning allSelected = true in the case of a programming error and giving no indication of any error is asking for trouble. I would code this scenario as
bool allSelected = ((CheckBoxList)row.FindControl("CheckBoxList1")) .Items .All(i=>i.Selected);AceCorban
Star
12358 Points
2274 Posts
Re: CheckBoxList Returning Check
Jan 24, 2013 02:58 PM|LINK
Indeed, mine was more a brute force method with the intent of polishing after we got to a concensus about where his confusion might have rested. Yours is a pretty elegant solution but, doesn't it still throw a null pointer exception if CheckboxList1 doesn't exist? Granted, it could still be caught, but if, for instance, the CheckBoxList in question is dynamically generated, then null may not be an application breaking scenario as much as it may be an acceptable execution path. To support that you'd need to surround this single line in a try-catch block to account for that possibility and allow execution to the following lines of code.
Paul Linton
Star
13431 Points
2535 Posts
Re: CheckBoxList Returning Check
Jan 24, 2013 07:36 PM|LINK
My main point was that if a NullRefernceException was to be generated then it is a good thing. It shows a programming error of some form. Perhaps the page was modified but the code behind was not or some dynamic control generation code has performed incorrectly. In whatever case it is truely exceptional and I would want to 'fail fast' so that I know where the problem is.
Personal opinion - I would not want try/catch around this, I want to fail and fix the coding error that the Exception repesents. There is nothing tha anyone, except the programmer, could do about the problem. Certainly, I don't want to assume success and hide the issue.
AceCorban
Star
12358 Points
2274 Posts
Re: CheckBoxList Returning Check
Jan 24, 2013 08:51 PM|LINK
I don't disagree, but I still come across instances where null pointers are legitimate (albeit rare) execution paths. Perhaps in an AJAX enviornment where input from the user is used to make deductions on the server. I don't think that is necessarily the case here, but it is an interesting point none-the-less. My point is, we don't truly know where this string "CheckboxList1" is coming from, and we cannot always trust the source. To have the application fail in such a manner looks to users as if it were broken when it might otherwise be more appropraite to degrade gracefully.