Handling problem with ListView.ItemCheck event

[Mike Ruane-Torr]

I have a design problem involving a ListView control on a Windows form.
What it boils down to is the following question:

Q: Is there a way to tell the difference between a ListView.ItemCheck
event that has occurred because of a mouse click on a Checkbox, and one
that has occurred because the .Checked property of an item has been
changed programatically?

More details if needed, but if you can answer the above, you'll have
solved the problem! :)

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

[Charles Law]

Hi Mike

I use the Infragistics components, and there is a BeforeCheck event.

What I am doing is allowing code to change the check state, but not the user
by clicking an item.

The way I got round the problem you illustrate is to implement the
BeforeCheck handler and always cancel the attempt to check/uncheck the box.
Then, in the code that is allowed to change the state, I remove the handler,
change the state, and then add the handler again. A bit crude, but it works.

Alternatively, set a flag before you make the change in code, and test the
flag in the BeforeCheck event.

One other possibility is that check boxes have an AutoCheck property. If you
set that to false it allows you to control when the check box is checked.

HTH

Charles
"Mike Ruane-Torr" <mike.ruane-torr@USE_EVENS_ixwiflaoyn.net> wrote in
message news:op**************@msnews.microsoft.com...

I have a design problem involving a ListView control on a Windows form.
What it boils down to is the following question:

Q: Is there a way to tell the difference between a ListView.ItemCheck
event that has occurred because of a mouse click on a Checkbox, and one
that has occurred because the .Checked property of an item has been
changed programatically?

More details if needed, but if you can answer the above, you'll have
solved the problem! :)

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

[Charles Law]

Hi Mike

I use the Infragistics components, and there is a BeforeCheck event.

What I am doing is allowing code to change the check state, but not the user
by clicking an item.

The way I got round the problem you illustrate is to implement the
BeforeCheck handler and always cancel the attempt to check/uncheck the box.
Then, in the code that is allowed to change the state, I remove the handler,
change the state, and then add the handler again. A bit crude, but it works.

Alternatively, set a flag before you make the change in code, and test the
flag in the BeforeCheck event.

One other possibility is that check boxes have an AutoCheck property. If you
set that to false it allows you to control when the check box is checked.

HTH

Charles
"Mike Ruane-Torr" <mike.ruane-torr@USE_EVENS_ixwiflaoyn.net> wrote in
message news:op**************@msnews.microsoft.com...

I have a design problem involving a ListView control on a Windows form.
What it boils down to is the following question:

Q: Is there a way to tell the difference between a ListView.ItemCheck
event that has occurred because of a mouse click on a Checkbox, and one
that has occurred because the .Checked property of an item has been
changed programatically?

More details if needed, but if you can answer the above, you'll have
solved the problem! :)

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

[Mike Ruane-Torr]

On Fri, 2 Apr 2004 14:58:01 +0100, Charles Law <bl***@nowhere.com> wrote:

The way I got round the problem you illustrate is to implement the
BeforeCheck handler and always cancel the attempt to check/uncheck the
box.
Then, in the code that is allowed to change the state, I remove the
handler,
change the state, and then add the handler again. A bit crude, but it
works. I considered this kind of approach, but thought that it might not be
thread-safe. Perhaps I should try it.
Alternatively, set a flag before you make the change in code, and test
the
flag in the BeforeCheck event.

I think that would definitely NOT be thread-safe.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

[Mike Ruane-Torr]

On Fri, 2 Apr 2004 14:58:01 +0100, Charles Law <bl***@nowhere.com> wrote:

The way I got round the problem you illustrate is to implement the
BeforeCheck handler and always cancel the attempt to check/uncheck the
box.
Then, in the code that is allowed to change the state, I remove the
handler,
change the state, and then add the handler again. A bit crude, but it
works. I considered this kind of approach, but thought that it might not be
thread-safe. Perhaps I should try it.
Alternatively, set a flag before you make the change in code, and test
the
flag in the BeforeCheck event.

I think that would definitely NOT be thread-safe.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/