4

How can I make an event that is raised when a variable or property is changed (or can I just put the code I would put in an event in the Set section of a property?

Jonathan.
  • 53,997
  • 54
  • 186
  • 290

4 Answers4

14

From the MSDN library entry INotifyPropertyChanged.PropertyChanged Event:

Public Class DemoCustomer
    Implements INotifyPropertyChanged

    Private customerNameValue As String = String.Empty

    Public Event PropertyChanged As PropertyChangedEventHandler _
        Implements INotifyPropertyChanged.PropertyChanged

    Private Sub NotifyPropertyChanged(ByVal info As String)
        RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs(info))
    End Sub

    Public Property CustomerName() As String
        Get
            Return Me.customerNameValue
        End Get

        Set(ByVal value As String)
            If Not (value = customerNameValue) Then
                Me.customerNameValue = value
                NotifyPropertyChanged("CustomerName")
            End If
        End Set
    End Property
End Class
Aviad P.
  • 32,036
  • 14
  • 103
  • 124
  • 1
    what would be the implications of just putting a `Sub` in the `Set` section of the property? – luchosrock Sep 11 '13 at 12:49
  • 4
    @luchosrock Personally, I think it's a bit lacking that you have to manually raise the event you've defined. If you could get the event to auto-raise then I see the point of defining an event, otherwise, just put the code - or a call to a Sub - in the setter. – SteveCinq Dec 16 '18 at 21:55
5

Yes, the best (if not the only) way of doing this is to completely hide the actual variable (make it Private) and expose it via a Property which fires events whenever the setter is used.

I do this regularly, but I've found that it's important to NOT raise the event if the new value is similar to the old value. This both eliminates unnecessary function calls and sometimes prevents recursive events.

David Rutten
  • 4,716
  • 6
  • 43
  • 72
  • Great point about not raising the event on a non-change -- I've seen this cause problems with WPF data binding. – itowlson Jan 03 '10 at 19:48
  • 1
    There often isn't any actual need for an event, remember that you can do almost anything within a setter. – Paul Creasey Jan 03 '10 at 20:00
  • what do you mean if they are similar? – Jonathan. Jan 03 '10 at 20:04
  • @Jonathan, let's say you have a Property that links to a Private integer called m_index. In the setter, *before* you raise the event, add this line: If (value = m_index) Then Return – David Rutten Jan 04 '10 at 09:33
1

The canonical event for this is the PropertyChanged event, which is defined in the INotifyPropertyChanged interface. You can raise this from your property setters. (Note that VB.NET will not raise the event for you: you must include the code to raise it.)

If the code you want to run on a change is logically part of your class (e.g. updating a customer status when the balance changes) then it is appropriate to put this in the property setter rather than in an event handler. Event handlers are for when external code needs to know about changes, e.g. to update the UI in response to the customer status changing.

itowlson
  • 73,686
  • 17
  • 161
  • 157
0

Take a look at this example implementation of the INotifyPropertyChanged interface, this is the standard method used for this functionality. The important parts are the NotifyPropertyChanged method and the code inside the property set handlers.

Rory
  • 2,722
  • 1
  • 20
  • 11