how do you overload methods...

[Benny Raymond]

I'm trying to change the way a treeview works just a bit, i'm pretty new
to C# and now i'm running into overloading. I tried the following code
and it's yelling at me saying that no overload method takes 0 arguments.

#region tViewNodeCollection
public class tViewNodeCollection : TreeNodeCollection
{
private tView _owner;
private tViewNode _parent;
/// <summary>
/// Create a collection within a tViewItem
/// </summary>
/// <param name="parent"></param>
public tViewNodeCollection(tViewNode parent)
{
_parent = parent;
}
/// <summary>
/// Create a new instance of tViewNodeCollection
/// </summary>
/// <param name="owner"></param>
public tViewNodeCollection(tView owner)
{
_owner = owner;
}
/// <summary>
/// Create a new instance of tViewNodeCollection
/// </summary>
/// <param name="owner"></param>
public tViewNodeCollection(tView owner, tViewNode parent)
{
_owner = owner;
_parent = parent;
}
}
#endregion


so then I tried a series of different :this(something) but that started
scaring me since I really don't understand overloading - Could someone
shed some light on this for me?

 

[Thomas P. Skinner [MVP]]

An overloaded method is a method that differs from all methods of the same
name in so far as it has a different number or types of its arguments. A
different return type does not constitute an overload. If you get an error
stating that no overload has 0 arguments then you are calling a method with
no arguments and you have no overloaded method that takes zero arguments.
Either instantiate the class with a constructor call with arguments or
provide an explicit constructor with zero arguments. In C# if you provide an
overloaded constructor you no longer get a default constructor (zero
arguments) and need to provide one. I think this is your problem.

Thomas P. Skinner [MVP]

 

[Mark Broadbent]

I believe that the constructor of the TreeViewCollection has been set to
private so effectively it can't be inherited.
The error message is a bit misleading though (it suggests that there is a
public constructor that does not have zero args - and hence in that case you
would be able to call it from your derived class) .

see for instance...
http://www.groupsrv.com/dotnet/viewtopic.php?t=16350

Hope this helps

Br,

Mark.

P.S.
Benny, although this is really something that is open to your/ your company
preference, when naming types you should (IMHO) not prefix them with
"t" -that is really a Delphi thing (but if it works for you then please
ignore my advice).

P.P.S.
You mention that you do not understand overloading, well in essence creating
an overload means that you are adding an additional function call to a class
which has the same name that is distinguished by it's type signature.
For instance

public void SayHello()
{SayHello();} //just calling overload method to save code in class

public void SayHello(string name)
{ string display = "Hello";
if name.Length > 0
display += name;
Console.WriteLine(display);
}

Which will mean that the Class would provide two method calls..
1 that allows you to SayHello without any arguments and the other to allow
you to SayHello with a string argument.

***I think you are also getting a little bit confused with overloading and
overriding - they are two DIFFERENT concepts. You should ideally read up on
both since they are crucial to good OOP***

 

[Thomas P. Skinner [MVP]]

A private constructor with zero args doesn't prevent inheritance from that
class. Basically the private constructor with zero args is normally used to
force the programming to instantiate the class with an overloaded
constructor. The derived class would need to explicitly invoke the
overloaded constructor in the base class.

The TreeNodeCollection does seem a bit strange in that no constructors are
documented. That would mean the class must be constructed via a public
static method. However I can't find one documented. It appears that the
TreeNodeCollection gets instantiated by the TreeView class by some subtle
method. In this case I agree that one can't inherit from TreeNodeCollection.
BTW, TreeNodeCollection is NOT documented as sealed. The result is the same
I guess. Interesting.

Thomas P. Skinner [MVP]

 

[Chris R. Timmons]

A private constructor with zero args doesn't prevent inheritance
from that class. Basically the private constructor with zero
args is normally used to force the programming to instantiate
the class with an overloaded constructor. The derived class
would need to explicitly invoke the overloaded constructor in
the base class.

The TreeNodeCollection does seem a bit strange in that no
constructors are documented. That would mean the class must be
constructed via a public static method. However I can't find one
documented. It appears that the TreeNodeCollection gets
instantiated by the TreeView class by some subtle method. In
this case I agree that one can't inherit from
TreeNodeCollection. BTW, TreeNodeCollection is NOT documented as
sealed. The result is the same I guess. Interesting.

Thomas,

Using Lutz Roeder's Reflector utility, it appears that
TreeNodeCollection's only constructor is scoped as internal. The
types w/i System.Windows.Forms.dll can use it like any other type,
but us poor serfs on the "outside" can't construct our own instances
of TreeNodeCollection :-(.

Chris.

 

[Thomas P. Skinner [MVP]]

Chris,

Now why didn't I think of that? This makes complete sense. I was thinking
maybe an undocumented static method or something, but internal is so much
simpler. Thanks for this info.

Thomas P. Skinner [MVP]

 

[Mark Broadbent]

Hi Thomas please see replies....

A private constructor with zero args doesn't prevent inheritance from that
class. Basically the private constructor with zero args is normally used to
force the programming to instantiate the class with an overloaded
constructor. The derived class would need to explicitly invoke the
overloaded constructor in the base class.

Incorrect - A private constructor *will* prevent inheritance *if* it is
the only constructor available in the class (which I suggested in the
original post). Your statement is correct only *if* there is an available
constructor visible to the code outside the class (public) or to the
inheriting class (protected - if both classes in same assembly). One reason
you might want to do this is to enforce strict object creation through an
object factory method. For instance the following class cannot be
inherited...
public class Parent
{
string name;
private Parent(string s) //only constructor: is private and prevents
inheritance since any inheriting classes cannot see the base constructor
{
name = s;
}

public static Parent CreateParent(string s)
{
if (s == null || s.Length == 0)
{
throw new Exception("Invalid string specified when building new
object");
}
return new Parent(s);
}
}

You are obviously correct is stating another reason why a private default
constructor is used -to enforce construction through an overloaded
constructor *although* this is strictly not necessary since a default
constructor is only used if :-
i. No constructor is specified in a class
ii. If the default constructor has been explicitly declared - which is the
default behaviour of Visual Studio code generator.
For instance the following code can only be created using the constructor
with a string params...

public class Class2
{
//the lack of default constructor effectively means that the class can
only
//be instanciated using the constructor with a string parameter.
public Class2(string s)
{
}
}

The TreeNodeCollection does seem a bit strange in that no constructors are
documented. That would mean the class must be constructed via a public
static method. However I can't find one documented. It appears that the
TreeNodeCollection gets instantiated by the TreeView class by some subtle
method. In this case I agree that one can't inherit from
TreeNodeCollection. BTW, TreeNodeCollection is NOT documented as sealed.
The result is the same I guess. Interesting.

Thankfully Chris has got to the bottom of this one. Interesting subject
this. Like you I noticed the lack of constructor documentation for this
class. I really wish Microsoft would document exactly the internals of the
class libraries -but I guess you cant have everything.

Best Regards,

Mark Broadbent.

 

[Thomas P. Skinner [MVP]]

Yes, but that's not what I said. Read it again at bit more carefully before
criticizing.. I was responding to a conjecture that a private default
constructor always prevents inheritance. It doesn't if there are public
overloaded constructors as you well point out. I never said a class with
ONLY a private default constructor can be inherited.

Thomas P. Skinner [MVP]

 

[Mark Broadbent]

1. I think you will find that you did implicitly say exactly that ...."A
private constructor with zero args doesn't prevent inheritance from that
class"
-since you were attempting to correct my original statement -which by the
way mentions NOTHING about overloaded constructor in the base class and in
addition nowhere in my statement do I say ALWAYS prevents -just in that one
instance.

2. I was not critizing, I was correcting (or for the sake of
Benny...clarifying your misleading statement). So before you start flaming
me please think about what you are saying and take time to read the posts
properly.

3. Your MVP doesnot entitle you to be correct on every occasion so get over
it and move on!

NUFF SAID!

 

[Thomas P. Skinner [MVP]]

Mark,

I apologize if I interpreted your original statement incorrectly. However I
believe the implication was that a private default constructor always
prevents inheritance even if you did not mention overloaded constructors or
the word always. My mistake. I think you were also a bit quick to jump on my
most recent statement. Nothing I said was incorrect as stated. I only made a
mistake on what I said because you misinterpreted it.

I will ignore comment 3 and get on with things.

Thomas P. Skinner [MVP]

 

[Ravichandran J.V.]

Overloading is simply a matter of giving same named methods/members of a
class a different signature. For example, if you want to create an
overloaded constructor, the assumption is that a default constructor
with no parameter exists.

public Class1()
{
// Default constructor
}

To overload the constructor, just create a different signature.
Difference in signatures can be by changing the return type or the
parameter list; in this case, since constructors do not have a return
type, change the parameter list as follows

public Class1(int x) // Parameter is created for this constructor thus
making it different from the existing constructor
{
// Overloaded constructor
}

Same principles apply to methods also.



with regards,


J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com