Changing CheckedState or Checked-value without raising ItemChecked-event

[Alexander Mueller]

Hi all,

in a CheckedListBox there are afaics two members that change the
checked-flag for an item i.e. SetItemChecked and SetItemCheckState.
In the online-help there is a remark that SetItemCheckState will raise
an ItemCheck-event. There is no such remark for SetItemChecked also
it also raises this event in a small testcase.
Is there any differnce between the two methods except that
SetItemCheckState allows setting the indifferent-state?
How can a checked-value be changed without raising the event?
I used to help myself with a workaround-helperflag like
m_bolHandleCheckedEvent on module-level in VB-6 and thought VB.NET was
smarter concerning this issue.
Is there a property of a CheckedListBox to dynamically suppress
ItemCheck-eventhandling?

Thanks for your help,
Alex

 

[Ken Tucker [MVP]]

Hi,

The event is going to be raised if you change the value of
checked-value. You need to use the same workaround in .net

Ken

 

[Cor Ligthert [MVP]]

Alexander,

In my opinion a nice way to handle the kind of problems you have. For a
former VB6 user it looks a little bit strange. This is a sample I made some
days ago however about the same problem.

The event in both procedures do raise each other and become than recursive.
By than temporaly remove the handler and set it back at the end, they don't
give a reaction.

\\\
Private Sub SplitContainer1_SplitterMoved(ByVal sender _
As System.Object, ByVal e As System.Windows.Forms.SplitterEventArgs) _
Handles SplitContainer1.SplitterMoved
RemoveHandler TextBox1.TextChanged, AddressOf TextBox1_TextChanged
TextBox1.Text = SplitContainer1.SplitterDistance.ToString
AddHandler TextBox1.TextChanged, AddressOf TextBox1_TextChanged
End Sub

Private Sub TextBox1_TextChanged(ByVal sender _
As System.Object, ByVal e As System.EventArgs) Handles
TextBox1.TextChanged
RemoveHandler SplitContainer1.SplitterMoved, AddressOf
SplitContainer1_SplitterMoved
If IsNumeric(TextBox1.Text) AndAlso CInt(TextBox1.Text) > 130 Then
SplitContainer1.SplitterDistance = CInt(TextBox1.Text)
End If
AddHandler SplitContainer1.SplitterMoved, AddressOf
SplitContainer1_SplitterMoved
End Sub
///

I hope this helps,

Cor

 

[Alexander Mueller]

In my opinion a nice way to handle the kind of problems you have. For a
former VB6 user it looks a little bit strange. This is a sample I made some
days ago however about the same problem.

The event in both procedures do raise each other and become than recursive.
By than temporaly remove the handler and set it back at the end, they don't
give a reaction.

\\\
Private Sub SplitContainer1_SplitterMoved(ByVal sender _
As System.Object, ByVal e As System.Windows.Forms.SplitterEventArgs) _
Handles SplitContainer1.SplitterMoved
RemoveHandler TextBox1.TextChanged, AddressOf TextBox1_TextChanged
TextBox1.Text = SplitContainer1.SplitterDistance.ToString
AddHandler TextBox1.TextChanged, AddressOf TextBox1_TextChanged
End Sub

Private Sub TextBox1_TextChanged(ByVal sender _
As System.Object, ByVal e As System.EventArgs) Handles
TextBox1.TextChanged
RemoveHandler SplitContainer1.SplitterMoved, AddressOf
SplitContainer1_SplitterMoved
If IsNumeric(TextBox1.Text) AndAlso CInt(TextBox1.Text) > 130 Then
SplitContainer1.SplitterDistance = CInt(TextBox1.Text)
End If
AddHandler SplitContainer1.SplitterMoved, AddressOf
SplitContainer1_SplitterMoved
End Sub
///

I hope this helps,

Hi Cor and Ken,

thanks very much both of you for your help.
The idea of dynamically removing and reenabling the handler is nice,
although takes quite some effort if you have multiple locations for
setting checked state. I thought i had read that NET-checkboxes
straighten up with VB-6-flaws like that changing the checked-state by
code raises a click-event. There should be to my opinion some kind of
information available as to what triggered the event (user-interaction,
code or external-incident, etc).
Anyway, now I have two ways to fix it, thanks again.

Mfg,
Alex

 

[Cor Ligthert [MVP]]

Alexander,

I thought i had read that NET-checkboxes
straighten up with VB-6-flaws like that changing the checked-state by
code raises a click-event. There should be to my opinion some kind of
information available as to what triggered the event (user-interaction,
code or external-incident, etc).

It is completely the same in C# and C++ managed.

There is by the way no click-event raised, you are not even busy with that,
the event are one of the property changed events.

All things I have tried in another way for this, did lead to a kind of
spagetti code.

Just my idea

Cor