inheritence

  • Thread starter Thread starter Craig Smesny
  • Start date Start date
C

Craig Smesny

I have a form(Call it form 1) that I use as a base class for other forms
in my application. it contains a a call to a function that passes its
form name. Form 2 inherits from form 1. When it is initialized and
calls the function from form 1, I need it to use the name from the
derived class not the base class. Can this be done in the base class or
do I have to override the function in the derived class? The whole
point of the baseclass was to include code that will be used on every
form it is based on and recognize the actual form being created.
Thanks
 
Yes, I do the same thing all the time, and it works without problems, except
for one strange phenomena I noticed. When I instance a form (form1) based on
another form (xform) then I noticed that when I instanciate form1, without
it containing any code, or having any properties set, it returns as name
xform (instead of form1, which is its name).
But as soon as I modify one property on form1, the instance returns its
proper name. I guess this is a bug in VB.

Hth,
Martin
 
Craig Smesny said:
I have a form(Call it form 1) that I use as a base class for other forms
in my application. it contains a a call to a function that passes its
form name.
Click to expand...

OK, starting to worry a little at that ...
Form 2 inherits from form 1. When it is initialized and calls the
function
from form 1, I need it to use the name from the derived class not the
base class.
Click to expand...

You should override the base function and provide your alternative
implementation.
Can this be done in the base class or do I have to override the function
in the derived class? The whole point of the baseclass was to include
code that will be used on every form it is based on and recognize the
actual form being created.
Click to expand...

IMHO, you're doing this the wrong way round.

Yes, your derived forms should be able to reuse the code in the Base
form, but the Base form /shouldn't/ know anything about the classes
derived from it - that would be like the Forms.Form class knowing about
every Form that any developer anywhere could ever possibly write.

Form specific "adaptations" should be done in the derived forms.
Your base code should remain generic.

Having said all that, if your form has a property like

Protected Overriable ReadOnly Property FormName() As String
Get
Return "Form1"
End Get
End Property

and each derived form overrides this, something like

Protected Overrides ReadOnly Property FormName() As String
Get
Return "Form2"
End Get
End Property

Then your base class /can/ safely use :

Select Case Me.FormName
Case "Form1"
Case "Form2"
.... etc ...
End Select

The "Me." always refers to the /actual/ instance of the class (in this case
yuor derived forms). if you have to restrict the code to only use code
in the base class, use "MyClass." instead.

HTH,
Phill W.
 
Hi Phil,

I agree with you a 100% that a base class shouldn't know anything about its
possible subclasses. However, the "Name" property, which is a general
property that is simply inherited from one of its ancestoral classes.

When I write in a class a function that, for instance, reports the contents
of its Name property to let's say an MDI container form, then there is
nothing wrong with that, even if the value of that Name property is set in
(an instance of) a subclass. That function is simply inherited by the
subclass from one of its ancestoral classes and is executed in the instance
of the subclass.
No need to override these properties, or create new properties that
basically do the same as inherited ones.

You do however create a prerequisite with such a function, and that is (in
my example) that for instances of the class always have their Name property
set. But this is the essence of Object Oriented Programming; The ultimate
superclass is very general, and gets more "specialized" with each subclass.

Martin
 
Back
Top