By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,911 Members | 1,124 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,911 IT Pros & Developers. It's quick & easy.

System.Windows.Forms.ListView: OnItemCheck method called when displaying the form

P: n/a
Is there any way to know whether the OnItemCheck is being called in response
to a user action (mouse or keyboard) as opposed to the form loading?

I have a class which derives from System.Windows.Forms.ListView. Among
other features, it enables the checkboxes and overrides the OnItemCheck()
method. I have placed this ListView on a form and use form.ShowDialog() to
display it whenever the user presses a certain button.

If the user ticks any of the items in the ListView, and then presses the
button again, the form displays okay, but it calls the OnItemCheck() method
twice for each item that was previously checked (once to uncheck, and again
to check the item).

The problem is, that I keep track of the order in which the user checked the
checkboxes, and when OnItemCheck is called it effectively changes the order
to be the same as the insertion order in the list.

Thanks,
Aaron Queenan.
Nov 15 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
100
Hi Aaron,
ItemCheck event is raised whenever an item changes its check status. It can
be done programmatically or by the user. There is no way to now how the item
has been changed its state.
However the control doesn't fire the event before it is created or if it is
created with Visible property set to false. Which means that you can fill up
and set the check status of the items without any ItemCheck event fired. But
once you show the control you cannot stop the events even if you set Visible
back to *false*.
I see that you have overridden the control. In this case you can add a
property say "bool SuppressItemCheckEvent";
If this flag is set in your OnItemCheck don't call base.OnItemCheck this
will suppress the event.
Now you can set
SuppressItemCheckEvent = true;
change the state of items
SuppressItemCheckEvent = false;

HTH
B\rgds
100

"Aaron Queenan" <aq*********************@contingent.com.au> wrote in message
news:u2**************@TK2MSFTNGP11.phx.gbl...
Is there any way to know whether the OnItemCheck is being called in response to a user action (mouse or keyboard) as opposed to the form loading?

I have a class which derives from System.Windows.Forms.ListView. Among
other features, it enables the checkboxes and overrides the OnItemCheck()
method. I have placed this ListView on a form and use form.ShowDialog() to display it whenever the user presses a certain button.

If the user ticks any of the items in the ListView, and then presses the
button again, the form displays okay, but it calls the OnItemCheck() method twice for each item that was previously checked (once to uncheck, and again to check the item).

The problem is, that I keep track of the order in which the user checked the checkboxes, and when OnItemCheck is called it effectively changes the order to be the same as the insertion order in the list.

Thanks,
Aaron Queenan.

Nov 15 '05 #2

P: n/a
I can get around the problem of the events firing on loading, by using the
following code at the top of OnItemCheck():

if (ice.Index >= this.Items.Count)
return;

However, the method still gets called if I hide then show the form. The
problem is that the ListView unchecks then rechecks each checked item in the
list. That is utterly stupid! The items haven't changed, and there is no
reason for anything to uncheck then recheck them, but perhaps when the form
recreates the underlying control the internal ListView illogic isn't clever
enough to realise that the events should be discarded, and calls
OnItemCheck().

Do you know what events fire before or after showing the form? Is there any
way to watch the events being fired, without handling them all? I am
thinking of setting a flag called "IgnoreBogusListViewEvents" in an event
which occurs first and clearing it afterwards.

Thanks,
Aaron.

"100" <10*@100.com> wrote in message
news:u3**************@TK2MSFTNGP10.phx.gbl...
Hi Aaron,
ItemCheck event is raised whenever an item changes its check status. It can be done programmatically or by the user. There is no way to now how the item has been changed its state.
However the control doesn't fire the event before it is created or if it is created with Visible property set to false. Which means that you can fill up and set the check status of the items without any ItemCheck event fired. But once you show the control you cannot stop the events even if you set Visible back to *false*.
I see that you have overridden the control. In this case you can add a
property say "bool SuppressItemCheckEvent";
If this flag is set in your OnItemCheck don't call base.OnItemCheck this
will suppress the event.
Now you can set
SuppressItemCheckEvent = true;
change the state of items
SuppressItemCheckEvent = false;

HTH
B\rgds
100

"Aaron Queenan" <aq*********************@contingent.com.au> wrote in message news:u2**************@TK2MSFTNGP11.phx.gbl...
Is there any way to know whether the OnItemCheck is being called in

response
to a user action (mouse or keyboard) as opposed to the form loading?

I have a class which derives from System.Windows.Forms.ListView. Among
other features, it enables the checkboxes and overrides the OnItemCheck() method. I have placed this ListView on a form and use form.ShowDialog()

to
display it whenever the user presses a certain button.

If the user ticks any of the items in the ListView, and then presses the
button again, the form displays okay, but it calls the OnItemCheck()

method
twice for each item that was previously checked (once to uncheck, and

again
to check the item).

The problem is, that I keep track of the order in which the user checked

the
checkboxes, and when OnItemCheck is called it effectively changes the

order
to be the same as the insertion order in the list.

Thanks,
Aaron Queenan.


Nov 15 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.