Click here to Skip to main content
15,936,821 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I created a base class with Overridable properties:
VB
Public Class MyBaseClass
Inherits Panel

  Public Overridable Property ProcessArguments As String = ""

  Public Overridable Property ProcessFilePath As String = ""

End Class

Then I added a derived class:
VB
Public Class MyDerivedClass
Inherits MyBaseClass

  Public Overrides Property ProcessArguments As String
    Get
      Return My.Settings.MyProcessArguments
    End Get
    Set(value As String)
      My.Settings.MyProcessArguments = value
      My.Settings.Save()
    End Set
  End Property

  Public Overrides Property ProcessFilePath As String
    Get
      Return My.Settings.MyProcessFilePath
    End Get
    Set(value As String)
      My.Settings.MyProcessFilePath = value
      My.Settings.Save()
    End Set
  End Property

End Class

I would expect VB to recognize the derived class' overrides, but when I add the derived panel to my form, the designer initializes it as such:
VB
'
'MyDerivedClass1
'
Me.MyDerivedClass1.Location = New System.Drawing.Point(13, 13)
Me.MyDerivedClass1.Name = "MyDerivedClass1"
Me.MyDerivedClass1.ProcessArguments = ""
Me.MyDerivedClass1.ProcessFilePath = ""
Me.MyDerivedClass1.Size = New System.Drawing.Size(184, 255)
Me.MyDerivedClass1.TabIndex = 2

Am I not overriding things properly? I have been coding for years and have used overridden properties and methods often. Any ideas?

I am coding using VS Community 2019 Version 16.3.9 and .NET Framework Version 4.8.03752, although the project is targeted to Framework Version 4.7.2.

Thank you in advance for any assistance!

What I have tried:

I have tried putting the base and derived class definitions in the same or different projects, with no difference in the result. I have also tried adorning the derived properties with a DesignerSerializationVisibilityAttribute set to Hidden (the designer still initializes it as shown above).

When I run the program, I get an empty string, even though the My.Settings values are set to appropriate string values.

I have Googled every set of keywords I can think of for this situation, but all I have found are examples of overrides without any references to it not working...
Posted
Updated 23-Jan-20 21:06pm

It's because you set an initializer on the base class - and the base class construction must be done before the derived class construction - so it's honouring that initializer. So it overwrites the values in your settings each time the class is constructed.

Take off the initialiser:
VB
Public Class MyBaseClass
    Inherits Panel

    Public Overridable Property ProcessArguments As String

    Public Overridable Property ProcessFilePath As String

End Class
And it'll do what you wanted it to. Sort of ...

Why "sort of"? Becuase it's also a pretty poor idea: it means that if any of your class instances sets a value, it will affect every class instance, and you won't have any control over who "wins" if you use them. I'd strongly suggest that you do this via a Shared property so it's more obvious that there can be only one backing store.
 
Share this answer
 
Comments
GRCook 24-Jan-20 22:45pm    
Thanks for your help. Removing the initializers did work, as far as the designer code was concerned. However, the designer property grid still didn't show the My.Settings values, so I decided to go another route and create a UI for application specs instead.

Your point about the multi-control conflict was also helpful, although this was intended to be a single-instance derived type.

I do wonder, however, if the base class initializer conflict goes against the concepts of inheritance and overrides? It would make sense for the base class to be initialized, but shouldn't the derived definition take precedence in the designer?
OriginalGriff 25-Jan-20 3:34am    
Why? The derived class is the base class with added functionality - so the base class has to be fully initialised before any derived class code can be executed (or it couldn't use any of the base class data or methods in it's initialiser. And the system doesn't know that you are effectively trying to override the base class initialiser!
Another suggestion - additional to the one from Griff :
If your BaseClass don't make any use of this Properties but you want to have them in later derived classes - perhaps an Interface could also be a good idea. An Interface makes sure that a derived classes really have this Properties ... AND ... you get also the ability to ask for it by Reflection (if nescessary or interesting).
 
Share this answer
 
Comments
GRCook 24-Jan-20 22:52pm    
Interfaces can be helpful, but in this case the base type was intended to be used generically - the derived class was simply to redirect the source for these properties and to add a few other things. Thanks for your input though!

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900