Cor Ligthert [MVP] schrieb:
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