Inheritance question

  • Thread starter Thread starter Flomo Togba Kwele
  • Start date Start date
F

Flomo Togba Kwele

My application consists of a single form with a panel on it. When the user selects a menu item, a
UserControl is loaded onto the panel.

All the UserControl forms are derived from ctrlForm.vb. I want to embed 4 Subversion keywords into
each UserControl. Each of these keywords would be represented by a string and generated before a
compile by an external program (svn). Each of the UserControls might have different values for each
of the 4 keywords.

If I define the keyword properties at the parent level (ctrlForm), I'll merely get its keywords
when I cast the derived UserControl to ctrlForm, rather than the keywords associated with the
derived UserControl.

Do I have to cast each UserControl to itself before I access the keyword properties?

TIA Flomo
--
 
Hello Flomo,

You need to cast the object to type which u want to get, so based on your
description (if i understood right), u need to cast to UserControl

---
WBR, Michael Nemtsev [.NET/C# MVP].
My blog: http://spaces.live.com/laflour
Team blog: http://devkids.blogspot.com/

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo

FK> My application consists of a single form with a panel on it. When
FK> the user selects a menu item, a UserControl is loaded onto the
FK> panel.
FK>
FK> All the UserControl forms are derived from ctrlForm.vb. I want to
FK> embed 4 Subversion keywords into each UserControl. Each of these
FK> keywords would be represented by a string and generated before a
FK> compile by an external program (svn). Each of the UserControls might
FK> have different values for each of the 4 keywords.
FK>
FK> If I define the keyword properties at the parent level (ctrlForm),
FK> I'll merely get its keywords when I cast the derived UserControl to
FK> ctrlForm, rather than the keywords associated with the derived
FK> UserControl.
FK>
FK> Do I have to cast each UserControl to itself before I access the
FK> keyword properties?
FK>
 
[...]
All the UserControl forms are derived from ctrlForm.vb. I want to embed
4 Subversion keywords into
each UserControl. Each of these keywords would be represented by a
string and generated before a
compile by an external program (svn). Each of the UserControls might
have different values for each
of the 4 keywords.

If I define the keyword properties at the parent level (ctrlForm), I'll
merely get its keywords
when I cast the derived UserControl to ctrlForm, rather than the
keywords associated with the
derived UserControl.

Do I have to cast each UserControl to itself before I access the keyword
properties?
Click to expand...

It depends on how you declare things. What I would do is define the
property in the base class, but then have the derived classes set the
property during construction. How exactly you'd do this given your
auto-generation of the values I can't say, since you didn't post any
specifics about how you're importing the strings, but it should be simple
enough for you to figure out.

This would kind of like how the Name property for Control inheritors works.

An alternative method would be to use a virtual property, so that
inheritors can explicitly return their own version of the property. I
think this is overkill if all you're doing is returning a different
string, but it should work too.

Pete
 
Thanks to both of you.

Peter, Subversion is a source control package. I wanted to try it in place of VSS. It is not
integrated with the IDE, but I'm getting used to that. It is integrated with Windows Explorer.

In each of the derived UserControls, I embed:

protected friend shadows _svnRevision As String = "$Revision$"
When I check in this program, it automatically checks in out again and fills in the keyword with
appropriate data, in this case:
protected friend shadows _svnRevision As String = "$Revision: 6 $"

I wanted to display the keyword values in an About box for each of the derived controls.

Thanks again, Flomo
 
In each of the derived UserControls, I embed:

protected friend shadows _svnRevision As String = "$Revision$"
When I check in this program, it automatically checks in out again and
fills in the keyword with
appropriate data, in this case:
protected friend shadows _svnRevision As String = "$Revision: 6 $"
Click to expand...

Well, I don't know whether the integration of Subversion to which Jon
directed you helps. But setting that aside for the moment, it seems to me
you could do something like this:

class Base
{
protected string _strRevision;
}

class Derived : Base
{
public Derived()
{
_strRevision = "$Revision$";
}
}

There are lots of variations on that theme, including the virtual property
I mentioned. But the basic idea is shown above. All you need is some
code in the derived class that in some way overrides the behavior of the
base class.

Pete
 
Jon, I found it easier to use Tortoise than Ankh.

Peter,

The reason I have to define the string again in the derived class is that its value gets changed
each time it is checked in. It's value is not a function of the IDE, but an outside event. The
source control changes the code where it sees keywords (e.g, $Date$ or $Revision$) and expands it
($Date$) to "$Date: 2007-05-25 10:57:56 -0700 (Fri, 25 May 2007) $" (for example).

Flomo
 
Flomo Togba Kwele said:
Jon, I found it easier to use Tortoise than Ankh.
Click to expand...

That's fair enough (although I've found Ankh to be pretty good) - but
it's not the same as saying it's not Subversion isn't integrated with
the IDE.
 
Jon Skeet said:
That's fair enough (although I've found Ankh to be pretty good) - but
it's not the same as saying it's not Subversion isn't integrated with
the IDE.
Click to expand...

Whoops, typo:

"That's not the same as saying that Subversion isn't integrated with
the IDE" is what I meant to write.
 
The reason I have to define the string again in the derived class is
that its value gets changed each time it is checked in.
Click to expand...

I don't see how you arrive at that conclusion. Why does the fact that the
value gets change affect where you have to declare the field that contains
the string?
It's value is not a function of the IDE, but an outside event. The
source control changes the code where it sees keywords (e.g, $Date$ or
$Revision$) and expands it
($Date$) to "$Date: 2007-05-25 10:57:56 -0700 (Fri, 25 May 2007) $" (for
example).
Click to expand...

Why does that prevent you from including the keywords in the derived class
rather than the base class?

There may well be some limitation that I don't understand. I haven't used
Subversion so I don't know exactly what its rules are. But given the
rules you've stated so far in this thread, the code I posted should work
fine.

If Subversion only looks for its keywords in field initializations that
are part of the field declaration, I could see that as being a problem.
But you haven't suggested that's the case, nor do I see why it would be.

Pete
 
Peter,

I do define the string in each of the derived classes as well as the base. But the property is
defined in the base class, as you suggested, which works perfectly. I am sorry if I gave you the
impression that I was putting the keywords in the base class.

I certainly do not want to appear as a Subversion expert - I just am trying to learn it. If a
module under source control contains a keyword, it is expanded in that module when it is committed
to the repository.

Flomo
 
I do define the string in each of the derived classes as well as the
base. But the property is
defined in the base class, as you suggested, which works perfectly. I am
sorry if I gave you the
impression that I was putting the keywords in the base class.
Click to expand...

I'm not sure what you mean by "define the string". I'm not talking about
declaring a field in the derived class. I'm just saying to initialize it
in the constructor of the derived class.
I certainly do not want to appear as a Subversion expert - I just am
trying to learn it. If a
module under source control contains a keyword, it is expanded in that
module when it is committed
to the repository.
Click to expand...

It will expand the keyword at *any* location within that file? If so,
then what I suggested should work.

Pete
 
Peter,

Sorry for the sloppy terminology.

In base:
Protected friend _svnDate As String = "$Date$"
Public Property SvnDate() As String
Get
Return _svnDate
End Get
Set(ByVal value As String)
_svnDate = value
End Set
End Property


In derived before committing this version containing keyword Date to Subversion:
protected friend shadows _svnDate As String = "$Date$"
Public Sub New()
svndate = _svndate
End Sub

After committing derived, as an example:
protected friend shadows _svnDate As String = "$Date: 2007-05-25 11:01:59 -0700 (Fri, 25 May
2007) $"
Public Sub New()
svndate = _svndate
End Sub

Flomo
 
Peter,

Sorry for the sloppy terminology.
Click to expand...

That's okay...just trying to make sure I understand the situation
correctly.

Based on the code you posted, I would recommend changing the derived
portion to read as follows:
In derived before committing this version containing keyword Date to
Subversion:
Public Sub New() _svndate = "$Date$"
End Sub
Click to expand...

You don't want a new field that shadows the base field, because of course
if you do that all you've done is hide the base field from the derived
field. The base class still has no way to see the new field in the
derived class, as you know.

Instead, the above code doesn't add a new field at all. It simply sets a
new default value to the field. Personally, I wouldn't make the property
"SvnDate" settable, but maybe you have a good reason for that. I don't
know. But the main thing is to just get the derived class to override the
*value* assigned to the field, by setting it in the constructor.

I took out the assigned of "svndate = _svndate" simply because it didn't
make any sense to me. You didn't post any code that declared something
named "svndate", so I'm guessing the "svndate" is actually the property
you defined (VB is case-insensitive? I don't do much VB stuff, so please
forgive my lack of familiarity with it). But if you set the underlying
field directly, there's no need to set the value again via the property
(and as I mentioned, I wouldn't make the property writeable anyway).

Pete
 
Peter,

Thanks for your patience. It takes me a while. Your suggestion works perfectly.

Flomo
 
Back
Top