How do I trigger a function on a custom event?

  • Thread starter Thread starter Anil Gupte
  • Start date Start date
A

Anil Gupte

I want a function to execute when a variable changes. How do I that?

Something like this:

Dim Paid as Boolean
AddEvent Paid.ValueChanged

Private Sub Paid_ValueChanged() handles Paid.ValueChanged
' Update a database
End Sub

TIA,
 
Hello Anil,
I want a function to execute when a variable changes. How do I that?

Something like this:

Dim Paid as Boolean
AddEvent Paid.ValueChanged
Private Sub Paid_ValueChanged() handles Paid.ValueChanged
' Update a database
End Sub
TIA,
Click to expand...

You need to change Paid into either a property
-------------------------------------------------------------
Private mPaid As Boolean
Public Property Paid() As Boolean
Get
Return mPaid
End Get
Set(ByVal Value As Boolean)
mPaid = Value
call Paid_ValueChanged()
End Set
End Property
Private Sub Paid_ValueChanged()
' Update a database
End Sub
-------------------------------------------------------------

or a method that accepts a param

-------------------------------------------------------------
Public Sub SetPaid(Value as Boolean)
mPaid = Value
Call Paid_ValueChanged
End Sub
Private Sub Paid_ValueChanged()
' Update a database
End Sub
 
Anil said:
I want a function to execute when a variable changes. How do I that?
Click to expand...

Variable? No can do.
Property? Sure ...

The conventional model goes something like this:

Class X
' An event that you can raise
Public Event YChanged( sender as Object, e as EventArgs )

' Property, the setting of which raises the event
Public Property Y() as Z
Get
Return m_Y
End Get
Set( value as Z )
m_Y = value
Me.OnYChanged( EventArgs.Empty )

' or (see (*) below)
YChangedEventArgs e = new YChangedEventArgs( ... )
Me.OnYChanged( e )

End Set
End Property

' A simple routine that raises the event
' (this can be called from subclasses)
Protected Overridable Sub OnYChanged( e as EventArgs )
RaiseEvent YChanged( Me, e )
End Sub

' local storage for the actual value
private m_Y as Z

' (*) And, if you want to go the whole hog ...
Public Class YChangedEventArgs
Inherits EventArgs

Friend Sub New( ... )
End Sub

End Class

End Class

HTH,
Phill W.
 
Thanx to both of you - sounds like it will have to be a property. I will
have to check this out and see if I can get it to work. Otherwise I will be
back with more questions.

BTW, I am not sure what you are showing in the ' (*) And, if you want to
go the whole hog ... section. Do you have an example link that explains
what that does and why it is better that way?

Thanx again,
 
Anil said:
BTW, I am not sure what you are showing in the ' (*) And, if you want to
go the whole hog ... section.
Click to expand...

Some event handlers, like the Click on a Button, don't need to know much
more than "something happened". That's all they need to be able to
"deal with" the event.

Lots of /other/ events need to tell their handlers a /lot/ more about
what's going on (e.g. the Mouse*, Drag*, and Layout events) and the
Event Arguments are an ideal, extensible way to pass this information
around (quite often this information would not normally be /accessible/
outside the class; it is provided only for the duration of the event).
Do you have an example link that explains what that does and why
it is better that way?
Click to expand...

Sadly not, but Our Friends in Redmond must think there's /some/ merit in
this approach; just how many classes /are/ there in the Framework
that derive from System.EventArgs?

Regards,
Phill W.
 
I tried your example and even simplified it. I have not finished yet, but
as far as I can tell there is nothing wrong in this:

Public Property Paid() As Boolean
Get
Return True
End Get
Set(ByVal Value As Boolean)
' mPaid = Value
call Paid_ValueChanged()
End Set
End Property
Private Sub Paid_ValueChanged()
' Update a database
End Sub

If <some condition> Then
Paid = True
End If

In other words I don't need mPaid. Am I right?
 
I tried your example and even simplified it. I have not finished yet, but
as far as I can tell there is nothing wrong in this:

Public Property Paid() As Boolean
Get
Return True
End Get
Set(ByVal Value As Boolean)
' mPaid = Value
call Paid_ValueChanged()
End Set
End Property
Private Sub Paid_ValueChanged()
' Update a database
End Sub

If <some condition> Then
Paid = True
End If

In other words I don't need mPaid. Am I right?
--
Anil Guptewww.keeninc.netwww.icinema.com


Hello Anil,
Click to expand...
You need to change Paid into either a
property -------------------------------------------------------------
Private mPaid As Boolean
Public Property Paid() As Boolean
Get
Return mPaid
End Get
Set(ByVal Value As Boolean)
mPaid = Value
call Paid_ValueChanged()
End Set
End Property
Private Sub Paid_ValueChanged() ' Update a database
End Sub
-------------------------------------------------------------
Click to expand...
or a method that accepts a param
Click to expand...
-------------------------------------------------------------
Public Sub SetPaid(Value as Boolean)
mPaid = Value
Call Paid_ValueChanged
End Sub Private Sub Paid_ValueChanged() ' Update a database
End Sub
-------------------------------------------------------------
Click to expand...
Click to expand...

Nothing wrong with it, a properties job to get and set a value, it
doesn't really matter whether it uses a private variable or not. What
I would recommend is that you don't save the value to a database every
time the value is set, it seems like it would cause way too much
network traffic. If you have a certain time you save the entire object
it might be best to do all the saves there, and just store the
property value in a variable until that time comes. Also, unless you
need to reuse the code in "Paid_ValueChanged()" you could just put
that code in the actual set block.

Thanks,

Seth Rowe
 
Hello Anil,
I tried your example and even simplified it. I have not finished yet,
but as far as I can tell there is nothing wrong in this:

Public Property Paid() As Boolean
Get
Return True
End Get
Set(ByVal Value As Boolean)
' mPaid = Value
call Paid_ValueChanged()
End Set
End Property
Private Sub Paid_ValueChanged()
' Update a database
End Sub
If <some condition> Then
Paid = True
End If
In other words I don't need mPaid. Am I right?
Click to expand...

Well I'm a little confused why you're always returning true as the value
of Paid. if this is the case then a WriteOnly property or a set Method might
suit better.

Also you're not doing anything with the incoming value when Paid is being
set.

Very confusing
 
Sorry that was one of my dumber ideas. You are right the property will
always retun true and that is not what I want. So I went back to your
original code. I should have thought about the implications for at least 10
minutes before posting the message. :-)

Thanx much.
 
Back
Top