how to select on the valid listview items?

Hi guys,

Can you please help me with my listview items. I want to know that when a user select the items on the listview to tick and untick on the checkboxes while a user do not select on the other listview items, how do the program suppose to know which listview items that a user have selected after tick and untick on the checkboxes?

Something like this:

Code:

---

for each (ListViewItem ^checkeditems in listView1::SelectedItems)
{
        if (checkeditems->Selected == true)
        {
        if (checkeditems->Checked == true)
        {
                checkeditems->Selected = false;
        }
        else if (checkeditems->Checked == false)
        {
                MessageBox::Show(checkeditems->SubItems[1]->Text);
        }
        }
}

---

I need to know how to do this because I want to send the information of substring text to my php server.

If you know how i can do this, I would be very grateful.

Thanks,
Mark

Quote:

---

Code:

---

(checkeditems->Selected == true)

---

---

Whenever you write "== true", god kills a sweet innocent kitten. You monster!

Seriously though, nobody has even the slightest chance of helping you unless you tell us what GUI framework this is.

Quote:

---

Originally Posted by Neo1

Whenever you write "== true", god kills a sweet innocent kitten. You monster!

---

If checkeditems->Selected is declared as "bool" that seems perfectly reasonable IMO.

Quote:

---

Originally Posted by Subsonics

If checkeditems->Selected is declared as "bool" that seems perfectly reasonable IMO.

---

No, "== true" is never reasonable.

Code:

---

(checkeditems->Selected == true)

---

Is equivalent to:

Code:

---

(checkeditems->Selected)

---

Writing "== true" is basically just another way of saying "i don't know how boolean-expressions work".

Quote:

---

Originally Posted by Neo1

another way of saying "i don't know how boolean-expressions work".

---

if it's a nullable bool, then "== true" is a perfectly valid expression, because System::Nullable<bool> doesn't implicitly convert to bool, but it does have an overloaded equality operator.

Quote:

---

Originally Posted by Elkvis

if it's a nullable bool, then "== true" is a perfectly valid expression, because System::Nullable<bool> doesn't implicitly convert to bool, but it does have an overloaded equality operator.

---

What's your point? The code in question is pseudo-code, we obviously aren't talking about nullables or tribools or whatever. My point still stands, using "== true" in a boolean expression is fundamentally wrong. You found an exception to this rule, have some cake.

Quote:

---

Originally Posted by Neo1

No, "== true" is never reasonable.

Code:

---

(checkeditems->Selected == true)

---

Is equivalent to:

Code:

---

(checkeditems->Selected)

---

Writing "== true" is basically just another way of saying "i don't know how boolean-expressions work".

---

So what, it comes down to opinion. You don't think it's reasonable because there is an equivalent short hand available, it's nothing wrong with explicitly typing it out. The short hand buys you nothing.

i prefer

Code:

---

(! checkeditems->Selected != true)

---

just to make people wonder :biggrin:
Kurt

Quote:

---

Originally Posted by Subsonics

So what, it comes down to opinion. You don't think it's reasonable because there is an equivalent short hand available, it's nothing wrong with explicitly typing it out. The short hand buys you nothing.

---

Wrong, my version is not shorthand for anything. There is something wrong with writing out " == true", if your expression evaluates to true, you don't then have to compare it to true, that's not the right way, that's stupid.

You're essentially asking your computer to compare true to true, or true to false.

Quote:

---

The short hand buys you nothing.

---

How does "true == true" buy you anything?

Do you also write:

Code:

---

if( x > 5 == true)

---

And would you consider:

Code:

---

if(x > 5)

---

..to be short hand?

Quote:

---

Originally Posted by Neo1

<snip>..to be short hand?

---

Yes. :D
Similarly, (expression !=NULL) is also often written, when applicable.
It simply increases the clarity, but can generally be skipped.

Quote:

---

Originally Posted by Neo1

Wrong, my version is not shorthand for anything. There is something wrong with writing out " == true", if your expression evaluates to true, you don't then have to compare it to true, that's not the right way, that's stupid.

You're essentially asking your computer to compare true to true, or true to false.

---

It's stupid to be confrontational. What am I doing? You say it's fundamentally wrong, which would mean that it's contrary to the standard, will result in undefined behavior, compile or runtime error.

Quote:

---

Originally Posted by Neo1

How does "true == true" buy you anything?

---

It doesn't but that is not what we are discussing here. "true == true" is known to be true, "x == true" can be true or false depending on the value of x.

Quote:

---

Originally Posted by Neo1

Do you also write:

Code:

---

if( x > 5 == true)

---

And would you consider:

Code:

---

if(x > 5)

---

..to be short hand?

---

This is not a matter of what I do or don't do. It's you trying to make this into an error, it's not. It's a valid expression.

Quote:

---

It's stupid to be confrontational. What am I doing? You say it's fundamentally wrong, which would mean that it's contrary to the standard, will result in undefined behavior, compile or runtime error.

---

This really has nothing to do with C or C++ or any standard, this transcends languages. This is a matter of a gross misunderstanding of boolean logic.

Quote:

---

It doesn't but that is not what we are discussing here. "true == true" is known to be true, "x == true" can be true or false depending on the value of x.

---

checkeditems->Selected is evaluated first, to either true or false. This is all you need to do. The OP then does a further comparison with true, which is completely redundant. After checkeditems->Selected is evaluated, the expression essentially becomes "true == true" or "false == true".

Quote:

---

This is not a matter of what I do or don't do. It's you trying to make this into an error, it's not. It's a valid expression.

---

There are many valid expressions in C and C++ that should be avoided. This code isn't wrong, and it will do what it was meant to, but it certainly won't make for very good code.

It's no different than this:

Code:

---

if( x > 5 == true)

---

So i will repeat the question that you so elegantly dodged, do you consider the above snippet of code to be good? If no, then you cannot logically find the code in the OP to be any better, if yes then you are beyond reasoning.

Quote:

---

Originally Posted by Neo1

It's no different than this:

Code:

---

if( x > 5 == true)

---

So i will repeat the question that you so elegantly dodged, do you consider the above snippet of code to be good? If no, then you cannot logically find the code in the OP to be any better, if yes then you are beyond reasoning.

---

It's a constructed scenario, I would not write something like that, ever. If you compare a bool, you can explicitly write out "== true" or "== false" if you think that makes the code more readable. It's a matter of style..

Should you use a or b? I don't care because it does not matter, it comes down to style. You clearly have a very strong opinion about it, to the point that you are trying to convince us that it's wrong

That is my only issue here, because that is a fallacy.

Quote:

---

Originally Posted by Subsonics

It's a constructed scenario, I would not write something like that, ever. If you compare a bool, you can explicitly write out "== true" or "== false" if you think that makes the code more readable. It's a matter of style..

Should you use a or b? I don't care because it does not matter, it comes down to style. You clearly have a very strong opinion about it, to the point that you are trying to convince us that it's wrong

That is my only issue here, because that is a fallacy.

---

Redundant code is wrong. I could throw in an i++; i--; in my code, and it would compile, and it would conform to the standard, and it would work. But it would be wrong. And i would get called out about it if i put up any such code on this board.
There must be a dozen beginning programmers in here every week, that get told to fix their indentation because it's wrong.
I could use goto's as a replacement for loops, and it would be wrong.
I could use preprocessor macros extensively in lieu of proper C++ control stuctures, and it would be wrong.

...it does not matter, it comes down to style.

Extremely poor style is wrong. Throwing in an extra comparison left and right for readabilities sake probably means your naming convention is off.

What is extremely poor, redundant etc. will vary depending on who you ask.

Quote:

---

Originally Posted by Subsonics

What is extremely poor, redundant etc. will vary depending on who you ask.

---

Boolean algebra is extremely well-defined, and you will find it is possible to mathematically prove what is redundant and what is not.

Fortunately, writing code is a science, more than it is an art.

Quote:

---

Originally Posted by Neo1

Boolean algebra is extremely well-defined, and you will find it is possible to mathematically prove what is redundant and what is not.

---

So what, C is not boolean algebra. What about descriptive variable and function names, or comments. Redundant?

Quote:

---

Originally Posted by Subsonics

So what, C is not boolean algebra. What about descriptive variable and function names, or comments. Redundant?

---

Hey man, you're the one defending the use of an extra comparison for purposes of styling. I'm all for descriptive names. Anything else would be wrong.

Quote:

---

Originally Posted by Neo1

Hey man, you're the one defending the use of an extra comparison for purposes of styling. I'm all for descriptive names. Anything else would be wrong.

---

Writing out "== true" does not result in a extra comparison. The comparison is made anyway but implicitly.

Quote:

---

Originally Posted by Subsonics

Writing out "== true" does not result in a extra comparison. The comparison is made anyway but implicitly.

---

Yes, the if-statement obviously means checking if the expression equals true, if you then put "== true" in the expression, you're doing an extra comparison. The compiler might do away with your redundant comparison, but then we don't want to rely on the compiler to fix our mess now do we?

how is any of this related to the OP's question?