Inheritance and Interfaces

[gwolinsky]

I originally posted this in the WindowsForms group but that may not
have been the best place to post it. So, I am reposting here.

--------------------------------------

I am trying to implement the new INotifyPropertyChanged interface in my
custom business object. The problem I'm having is with the inheritance
model.

I have a base object called "Person". The object "Employee" inherits
from person and provides additional properties and methods.

I implemented INotifyPropertyChanged in the Person base class and
everything worked great. However, how do I implement it in the derived
"Employee" class.

If I implement it the same way, the compiler warns that:

"event 'PropertyChanged' conflicts with event 'PropertyChanged' in the
base class 'Person' and should be declared 'Shadows'."

OK. So I change the event definition to "Shadows". Then, I still get
the following warning:

"'System.ComponentModel.INotifyPropertyChanged.Pro pertyChanged' is
already implemented by the base class 'Common.Person'.
Re-implementation of event assumed."

If I ignore BOTH warnings and run it, it works fine. If I designate
the event as "Shadows" and run it, it works fine.

Am I doing this correctly or am I in high weeds?

Any help would be greatly appreciated.

Sincerely,
Glen Wolinsky

[Jay B. Harlow [MVP - Outlook]]

Glen,
You only need to implement INotifyPropertyChanged in the base class, then
allow derived classes to raise the event. The "standard" pattern is to do
something like:

Public Class Person
Implements System.ComponentModel.INotifyPropertyChanged

Public Event PropertyChanged(ByVal sender As Object, ByVal e As
System.ComponentModel.PropertyChangedEventArgs) Implements
System.ComponentModel.INotifyPropertyChanged.Prope rtyChanged

Protected Overridable Sub OnPropertyChanged(ByVal e As
System.ComponentModel.PropertyChangedEventArgs)
RaiseEvent PropertyChanged(Me, e)
End Sub

Private m_name As String

Public Property Name() As String
Get
Return m_name
End Get
Set(ByVal value As String)
m_name = value
Dim e As New
System.ComponentModel.PropertyChangedEventArgs("Na me")
OnPropertyChanged(e)
End Set
End Property

End Class

Public Class Employee
Inherits Person

Private m_salary As String

Public Property Salary() As String
Get
Return m_salary
End Get
Set(ByVal value As String)
m_salary = value
Dim e As New
System.ComponentModel.PropertyChangedEventArgs("Sa lary")
OnPropertyChanged(e)
End Set
End Property

End Class

The Overridable Sub OnPropertyChanged allows derived classes to raise the
event, alternatively derived class can override the method & offer extra
processing when the event is raised...

For details on the above pattern see:

http://msdn.microsoft.com/library/de...Guidelines.asp

http://msdn.microsoft.com/library/de...Guidelines.asp

--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
<gw*******@millermartin.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com...
|I originally posted this in the WindowsForms group but that may not
| have been the best place to post it. So, I am reposting here.
|
| --------------------------------------
|
| I am trying to implement the new INotifyPropertyChanged interface in my
| custom business object. The problem I'm having is with the inheritance
| model.
|
| I have a base object called "Person". The object "Employee" inherits
| from person and provides additional properties and methods.
|
| I implemented INotifyPropertyChanged in the Person base class and
| everything worked great. However, how do I implement it in the derived
| "Employee" class.
|
| If I implement it the same way, the compiler warns that:
|
| "event 'PropertyChanged' conflicts with event 'PropertyChanged' in the
| base class 'Person' and should be declared 'Shadows'."
|
| OK. So I change the event definition to "Shadows". Then, I still get
| the following warning:
|
| "'System.ComponentModel.INotifyPropertyChanged.Pro pertyChanged' is
| already implemented by the base class 'Common.Person'.
| Re-implementation of event assumed."
|
| If I ignore BOTH warnings and run it, it works fine. If I designate
| the event as "Shadows" and run it, it works fine.
|
| Am I doing this correctly or am I in high weeds?
|
| Any help would be greatly appreciated.
|
| Sincerely,
| Glen Wolinsky
|

[Glen Wolinsky]

Jay,

Talk about having a "duh" moment. That works perfectly. I REALLY don't
know why I didn't think of it.

However, at the risk of repeating the "duh" offense, I am also trying to
implement the IDataErrorInfo interface. The difference here is that the
items I'm dealing with are not methods as in the INotifyPropertyChanged
interface. IDataErrorInfo implements two properties. I'm running into
the same problem as described previously.

Do you have another bit of charity for this VERY tired amateur? ;o)

Thanks,
Glen

"Jay B. Harlow [MVP - Outlook]" wrote:

Glen,
You only need to implement INotifyPropertyChanged in the base class, thenallow derived classes to raise the event. The "standard" pattern is to dosomething like:

Public Class Person
Implements System.ComponentModel.INotifyPropertyChanged

Public Event PropertyChanged(ByVal sender As Object, ByVal e As
System.ComponentModel.PropertyChangedEventArgs) Implements
System.ComponentModel.INotifyPropertyChanged.Prop ertyChanged

Protected Overridable Sub OnPropertyChanged(ByVal e As
System.ComponentModel.PropertyChangedEventArgs)
RaiseEvent PropertyChanged(Me, e)
End Sub

Private m_name As String

Public Property Name() As String
Get
Return m_name
End Get
Set(ByVal value As String)
m_name = value
Dim e As New
System.ComponentModel.PropertyChangedEventArgs("N ame")
OnPropertyChanged(e)
End Set
End Property

End Class

Public Class Employee
Inherits Person

Private m_salary As String

Public Property Salary() As String
Get
Return m_salary
End Get
Set(ByVal value As String)
m_salary = value
Dim e As New
System.ComponentModel.PropertyChangedEventArgs("S alary")
OnPropertyChanged(e)
End Set
End Property

End Class

The Overridable Sub OnPropertyChanged allows derived classes to raise theevent, alternatively derived class can override the method & offer extraprocessing when the event is raised...

For details on the above pattern see:

http://msdn.microsoft.com/library/de...y/en-us/cpgenr ef/html/cpconEventNamingGuidelines.asp
http://msdn.microsoft.com/library/de...y/en-us/cpgenr ef/html/cpconEventUsageGuidelines.asp
--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
<gw*******@millermartin.com> wrote in message
news:11*********************@g49g2000cwa.googlegr oups.com...
|I originally posted this in the WindowsForms group but that may not
| have been the best place to post it. So, I am reposting here.
|
| --------------------------------------
|
| I am trying to implement the new INotifyPropertyChanged interface in my| custom business object. The problem I'm having is with the inheritance| model.
|
| I have a base object called "Person". The object "Employee" inherits
| from person and provides additional properties and methods.
|
| I implemented INotifyPropertyChanged in the Person base class and
| everything worked great. However, how do I implement it in the derived| "Employee" class.
|
| If I implement it the same way, the compiler warns that:
|
| "event 'PropertyChanged' conflicts with event 'PropertyChanged' in the| base class 'Person' and should be declared 'Shadows'."
|
| OK. So I change the event definition to "Shadows". Then, I still get| the following warning:
|
| "'System.ComponentModel.INotifyPropertyChanged.Pro pertyChanged' is
| already implemented by the base class 'Common.Person'.
| Re-implementation of event assumed."
|
| If I ignore BOTH warnings and run it, it works fine. If I designate
| the event as "Shadows" and run it, it works fine.
|
| Am I doing this correctly or am I in high weeds?
|
| Any help would be greatly appreciated.
|
| Sincerely,
| Glen Wolinsky
|

--
Sent via .NET Newsgroups
http://www.dotnetnewsgroups.com

[Jay B. Harlow [MVP - Outlook]]

Glen,
I would do something like:

'
' Copyright © 2005, Jay B. Harlow, All Rights Reserved.
'
Option Strict On
Option Explicit On

Imports System.ComponentModel

Public Class Person
Implements INotifyPropertyChanged
Implements IDataErrorInfo

Private m_name As String

Public Property Name() As String
Get
Return m_name
End Get
Set(ByVal value As String)
If value = "" Then
ColumnError("Salary") = "Name is blank!"
Else
ColumnError("Salary") = ""
End If
m_name = value
Dim e As New PropertyChangedEventArgs("Name")
OnPropertyChanged(e)
End Set
End Property

#Region " INotifyPropertyChanged support "

Public Event PropertyChanged(ByVal sender As Object, ByVal e As
PropertyChangedEventArgs) Implements INotifyPropertyChanged.PropertyChanged

Protected Overridable Sub OnPropertyChanged(ByVal e As
PropertyChangedEventArgs)
RaiseEvent PropertyChanged(Me, e)
End Sub

#End Region

#Region " IDataErrorInfo support "

Private m_rowError As String
Private m_columnErrors As New
System.Collections.Specialized.StringDictionary

Private ReadOnly Property IDataErrorInfo_Error() As String Implements
IDataErrorInfo.Error
Get
Return m_rowError
End Get
End Property

Private ReadOnly Property IDataErrorInfo_Item(ByVal columnName As
String) As String Implements IDataErrorInfo.Item
Get
Return m_columnErrors(columnName)
End Get
End Property

Public Property RowError() As String
Get
Return m_rowError
End Get
Set(ByVal value As String)
m_rowError = value
End Set
End Property

Public Property ColumnError(ByVal columnName As String) As String
Get
Return m_columnErrors(columnName)
End Get
Set(ByVal value As String)
m_columnErrors(columnName) = value
End Set
End Property

Public Sub ClearErrors()
m_rowError = ""
m_columnErrors.Clear()
End Sub
#End Region

End Class

Public Class Employee
Inherits Person

Private m_salary As Decimal

Public Property Salary() As Decimal
Get
Return m_salary
End Get
Set(ByVal value As Decimal)
If value < 0 Then
ColumnError("Salary") = "Salary less then 0!"
Else
ColumnError("Salary") = ""
End If
m_salary = value
Dim e As New PropertyChangedEventArgs("Salary")
OnPropertyChanged(e)
End Set
End Property

End Class

NOTE: I did not add error checking to the ColumnError or RowError
properties...

--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"Glen Wolinsky" <gw*******@millermartin.com> wrote in message
news:OV**************@TK2MSFTNGP10.phx.gbl...
| Jay,
|
| Talk about having a "duh" moment. That works perfectly. I REALLY don't
| know why I didn't think of it.
|
| However, at the risk of repeating the "duh" offense, I am also trying to
| implement the IDataErrorInfo interface. The difference here is that the
| items I'm dealing with are not methods as in the INotifyPropertyChanged
| interface. IDataErrorInfo implements two properties. I'm running into
| the same problem as described previously.
|
| Do you have another bit of charity for this VERY tired amateur? ;o)
|
| Thanks,
| Glen
|
<<snip>>

[Glen Wolinsky]

That did the trick. I made a few modifications for our setup, but your
solution was right on the mark. Thank you SO much for your time and
assistance.

Sincerely,
Glen Wolinsky

--
Sent via .NET Newsgroups
http://www.dotnetnewsgroups.com

[Glen Wolinsky]

Jay,

One other question: What is your idea for providing an "IsValid"
property to a derived object with collections? This would be so that
the UI could let the object tell it if writting the changes is allowed
or if there are still problems with data.

Again, thanks for your time.

Sincerely,
Glen

--
Sent via .NET Newsgroups
http://www.dotnetnewsgroups.com

[Jay B. Harlow [MVP - Outlook]]

Glen,
I don't follow the question.

I would expect the object to let the UI know if its ok for the UI to tell
the object to save itself. If the UI attempted to save the object & the
object wasn't valid I would expect the object to let the UI know that its
not appropriate to save object at this time.

So yes, a "IsValid" can be appropriate property for an object to have,
however I would expect it would be public read-only & protected writable.

Note you need VB 2005 for public read-only & protected writable properties.

--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"Glen Wolinsky" <gw*******@millermartin.com> wrote in message
news:O5*************@TK2MSFTNGP15.phx.gbl...
| Jay,
|
| One other question: What is your idea for providing an "IsValid"
| property to a derived object with collections? This would be so that
| the UI could let the object tell it if writting the changes is allowed
| or if there are still problems with data.
|
| Again, thanks for your time.
|
| Sincerely,
| Glen
|
| --
| Sent via .NET Newsgroups
| http://www.dotnetnewsgroups.com

[Glen Wolinsky]

Jay,

Sorry if I wasn't very clear. We're on the same page in regards to
providing an "IsValid" property. My question is to the best way to
provide it.

Your scenario only updates the validity of a property IF the property
was set during its life. It seems to me (unless I'm missing something
-- very possible) that the object couldn't be sure if it's valid unless
it iterated through ALL the property checks when "IsValid" is read.
That would be the only way to ensure that all validations are hit.

Am I on it or off in high weeds?

Below, I am enclosing some code that I had started on this morning after
my last reply. I hope it makes some sense.

Thanks,
Glen
--------------------------------
This goes in my base class:
--------------------------------

Public ReadOnly Property ErrorsList() As Specialized.StringDictionary
Get
Return _itemErrors
End Get
End Property
Public MustOverride ReadOnly Property IsValid() As Boolean

Protected MustOverride Sub ValidateItem(ByVal ItemName As String)
Protected MustOverride Sub ValidateAllItems()

--------------------------------
This goes in my derived class:
--------------------------------

Public ReadOnly Property ErrorsList() As Specialized.StringDictionary
Get
Return _itemErrors
End Get
End Property

#Region " Validate Item (Override) "
Protected Overrides Sub ValidateItem(ByVal ItemName As String)
Select Case ItemName
Case "FirstName"
MyBase.ItemErrors("FirstName") = IIf(MyBase.FirstName = "", "First
Name is required.", "").ToString
Case "Initials"
MyBase.ItemErrors("Initials") = IIf(_initials = "", "Initials are
required.", "").ToString
Etc...
Case Else 'Do nothing.
End Select
End Sub
#End Region

#Region " Validate All Items (Override) "
Protected Overrides Sub ValidateAllItems()
ValidateItem("FirstName")
ValidateItem("Initials")
Etc.....
End Sub
#End Region

--
Sent via .NET Newsgroups
http://www.dotnetnewsgroups.com

[Jay B. Harlow [MVP - Outlook]]

Glen,
When the object is created it would know if it was valid or not. You can
insure this by using the properties for initialization instead of the
backing fields.

As the user changed properties they would know if the individual properties
were valid or not.

"Invalid" properties would (should) show up in the _itemErrors collection.

IsValid could be (would be!) as simply as "Return _itemErrors.Count = 0"
assuming _itemErrors only contained errors & did not contain successes...

--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"Glen Wolinsky" <gw*******@millermartin.com> wrote in message
news:el**************@TK2MSFTNGP12.phx.gbl...
| Jay,
|
| Sorry if I wasn't very clear. We're on the same page in regards to
| providing an "IsValid" property. My question is to the best way to
| provide it.
|
| Your scenario only updates the validity of a property IF the property
| was set during its life. It seems to me (unless I'm missing something
| -- very possible) that the object couldn't be sure if it's valid unless
| it iterated through ALL the property checks when "IsValid" is read.
| That would be the only way to ensure that all validations are hit.
|
| Am I on it or off in high weeds?
|
| Below, I am enclosing some code that I had started on this morning after
| my last reply. I hope it makes some sense.
|
| Thanks,
| Glen
|
|
| --------------------------------
| This goes in my base class:
| --------------------------------
|
| Public ReadOnly Property ErrorsList() As Specialized.StringDictionary
| Get
| Return _itemErrors
| End Get
| End Property
|
|
| Public MustOverride ReadOnly Property IsValid() As Boolean
|
| Protected MustOverride Sub ValidateItem(ByVal ItemName As String)
| Protected MustOverride Sub ValidateAllItems()
|
| --------------------------------
| This goes in my derived class:
| --------------------------------
|
| Public ReadOnly Property ErrorsList() As Specialized.StringDictionary
| Get
| Return _itemErrors
| End Get
| End Property
|
| #Region " Validate Item (Override) "
| Protected Overrides Sub ValidateItem(ByVal ItemName As String)
| Select Case ItemName
| Case "FirstName"
| MyBase.ItemErrors("FirstName") = IIf(MyBase.FirstName = "", "First
| Name is required.", "").ToString
| Case "Initials"
| MyBase.ItemErrors("Initials") = IIf(_initials = "", "Initials are
| required.", "").ToString
| Etc...
| Case Else 'Do nothing.
| End Select
| End Sub
| #End Region
|
| #Region " Validate All Items (Override) "
| Protected Overrides Sub ValidateAllItems()
| ValidateItem("FirstName")
| ValidateItem("Initials")
| Etc.....
| End Sub
| #End Region
|
|
|
| --
| Sent via .NET Newsgroups
| http://www.dotnetnewsgroups.com

[Glen Wolinsky]

Jay,

There are two ways my objects are initialized:

1. If this is a "get" operation, the object loads the employee data from
the database and sets all the backing fields;

2. This is a new employee and the backing fields are initialized during
variable instantiation.

Option 2 should be full of errors since it's empty and there are several
required fields. Option 1 would have to use the properties instead of
the backing fields like you mentioned in order make sure the current
data is valid.

So, in order to be consistent, are you saying I should initialize the
"properties" (not the backing variables) in a subroutine that is called
by both the constructor AND the "Get" routine?

Thanks,
Glen

--
Sent via .NET Newsgroups
http://www.dotnetnewsgroups.com

[Jay B. Harlow [MVP - Outlook]]

Glen,
| So, in order to be consistent, are you saying I should initialize the
| "properties" (not the backing variables) in a subroutine that is called
| by both the constructor AND the "Get" routine?
Yes.
--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"Glen Wolinsky" <gw*******@millermartin.com> wrote in message
news:uV****************@TK2MSFTNGP10.phx.gbl...
| Jay,
|
| There are two ways my objects are initialized:
|
| 1. If this is a "get" operation, the object loads the employee data from
| the database and sets all the backing fields;
|
| 2. This is a new employee and the backing fields are initialized during
| variable instantiation.
|
| Option 2 should be full of errors since it's empty and there are several
| required fields. Option 1 would have to use the properties instead of
| the backing fields like you mentioned in order make sure the current
| data is valid.
|
| So, in order to be consistent, are you saying I should initialize the
| "properties" (not the backing variables) in a subroutine that is called
| by both the constructor AND the "Get" routine?
|
| Thanks,
| Glen
|
| --
| Sent via .NET Newsgroups
| http://www.dotnetnewsgroups.com

[Glen Wolinsky]

Jay,

You have been a tremendous help. Thank you and God bless.

Sincerely,
Glen Wolinsky

--
Sent via .NET Newsgroups
http://www.dotnetnewsgroups.com

[Glen Wolinsky]

Jay,

Just when you thought it was safe to back into the forum.....I'm back.
;o)

I am implementing the solution we discussed. Everything seemed to be
working fine except for one issue.

My boss did not like the fact that on a NEW employee, the data entry
screen came up not only blank (as it should be) but with ALL the error
indicators already on (because I run the Employee.Validate routine
during construction that validates everything in the object). What he
wanted was that when the entry screen initially appears, there are no
validation errors. Then as the user attempts data entry, the validation
happens on a per-field basis. If the programmer attempts to run the ADD
or UPDATE routines in the Employee object, the object runs that full
validation routine and if it's NOT valid throws an exception.

I thought, "Ok, I'll just NOT run the full validation when the employee
object is constructed. Then, the individual property set routines will
validate on each one." Well, the problem is that when the user is
tabbing through blank fields (which shouldn't be blank) the values
aren't changing so the validation routines aren't running and the
errorproviders aren't showing.

Now for even stranger things. I put a test button on the form. This
button does nothing but run the employee object's full validate routine
(mentioned above) which just runs the validation routines on ALL the
properties. I thought this would make all the validators show up, but
they don't!!

Now, after trying that full validation, I change any field on the form
so that the validation fires, ALL the OTHER validations suddenly
appear!!!

I also found that when I use that test button to try and validate
EVERYTHING, if -- in the employee object -- I run the OnChangedProperty
event for each property after the property is validated, the
errorproviders show up.

Does any of this make sense? If so, do you have any more tricks in your
bag?

As before, your help would be grealy appreciated.

Sincerely,
Glen
--
Sent via .NET Newsgroups
http://www.dotnetnewsgroups.com

[Phill. W]

<gw*******@millermartin.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com...

I implemented INotifyPropertyChanged in the Person base class and
everything worked great. However, how do I implement it in the
derived "Employee" class.

This may be too little, too late, but I'll pitch in anyway in the hope
that, if I've been doing it completely wrong[ly?], someone will set
me straight.

I implement the Interface in the Base class, but make the
"implementing" routine Overridable. Each subclass can then supply
its own implementation that gets used instead of that in the Base class.

Class base
Implements ISomeInterface
Private Overridable Sub s1() _
Implements ISomeInterface.s1
. . .
End Class

Class derived
Inherits base
Private Overrides Sub s1()
. . .
End Class

Comments/Suggestions/derisory laughter, anyone?

Regards,
Phill W.

[Glen Wolinsky]

Phill,

In my numerous mutations of the code I was working with, I tried exactly
what you described. At least in regards to the IDataErrorInfo
interface, the behind-the-scenes wiring didn't work properly in the
subclasses or class-properties. Of course, it's entirely possible that
there was something else wrong with the code I tried.

My .02

Sincerely,
Glen
--
Sent via .NET Newsgroups
http://www.dotnetnewsgroups.com

[Jay B. Harlow [MVP - Outlook]]

Jay,
| Does any of this make sense? If so, do you have any more tricks in your
| bag?
Yes it makes sense, unfortunately I have not yet had time to look at it to
offer any sound advice.

--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"Glen Wolinsky" <gw*******@millermartin.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
| Jay,
|
| Just when you thought it was safe to back into the forum.....I'm back.
| ;o)
|
| I am implementing the solution we discussed. Everything seemed to be
| working fine except for one issue.
|
| My boss did not like the fact that on a NEW employee, the data entry
| screen came up not only blank (as it should be) but with ALL the error
| indicators already on (because I run the Employee.Validate routine
| during construction that validates everything in the object). What he
| wanted was that when the entry screen initially appears, there are no
| validation errors. Then as the user attempts data entry, the validation
| happens on a per-field basis. If the programmer attempts to run the ADD
| or UPDATE routines in the Employee object, the object runs that full
| validation routine and if it's NOT valid throws an exception.
|
| I thought, "Ok, I'll just NOT run the full validation when the employee
| object is constructed. Then, the individual property set routines will
| validate on each one." Well, the problem is that when the user is
| tabbing through blank fields (which shouldn't be blank) the values
| aren't changing so the validation routines aren't running and the
| errorproviders aren't showing.
|
| Now for even stranger things. I put a test button on the form. This
| button does nothing but run the employee object's full validate routine
| (mentioned above) which just runs the validation routines on ALL the
| properties. I thought this would make all the validators show up, but
| they don't!!
|
| Now, after trying that full validation, I change any field on the form
| so that the validation fires, ALL the OTHER validations suddenly
| appear!!!
|
| I also found that when I use that test button to try and validate
| EVERYTHING, if -- in the employee object -- I run the OnChangedProperty
| event for each property after the property is validated, the
| errorproviders show up.
|
| Does any of this make sense? If so, do you have any more tricks in your
| bag?
|
| As before, your help would be grealy appreciated.
|
| Sincerely,
| Glen
|
|
| --
| Sent via .NET Newsgroups
| http://www.dotnetnewsgroups.com