That is basically correct but the proper way to implement such an event is like this:
Public Property RetainSelBlock() As Boolean
Get
Return sprSpread.RetainSelBlock
End Get
Set
If sprSpread.RetainSelBlock <> value Then
sprSpread.RetainSelBlock = value
OnRetainSelBlockChanged(EventArgs.Empty)
End If
End Set
End Property
Public Event RetainSelBlockChanged As EventHandler
Protected Overridable Sub OnRetainSelBlockChanged(e As EventArgs)
RaiseEvent RetainSelBlockChanged(Me, e)
End Sub
Note that, in this case, the event is only raised if the property value actually changes. If you assign the same value to the property again, the event will not be raised again. Also, this code follows the intended pattern of using the EventHandler
delegate so that event handlers have the intended consistent signature, as well as raising the event only via a dedicated method that can be overridden in derived classes to provide custom behaviour on the inherited event.
Note that you could also implement the INotifyPropertyChanged
interface in the class that has that property and then raise the PropertyChanged
event. That might actually be closer to the VB6 way of doing things although I'm not sure. The nice thing about that is that you only have one event so you write less code in the producer and the consumer, so it's nice if you have lots of properties. The downside is that you then have to write conditional code in the consumer to determine which property changed, rather than having distinct event handlers for each property.
EDIT: Also not the more correct name of 'RetainSelBlockChanged' rather than RetainSelBlockChange
. It is convention to use a suffix of "Changed" for an event that is raised after a property value changes and "Changing" for an event that is raised before a property changes and allows you to cancel the change.