By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,889 Members | 1,297 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,889 IT Pros & Developers. It's quick & easy.

Static Methods

P: n/a
Hello, hoping you can clear up a little bit of confusion that I have on
creating/using static methods.

I want to create a class which hold all my "Utility Methods" for windows
forms. So I created a new project and added that project to my existing
project. The project "type" I selected was a "Class Library". What
this a correct choice.

So if I want to create "Static" methods, does the class itself have to
be static? There is no real reason to instatiate the class, so I am
guessing that I should make the class static. When I attempt to do
this, it tells me the modifier is not valid for this item. Have I got
the wrong format, or the wrong idea? Here is my code...

namespace WindowFormsUtilities
{
/// <summary>
/// Summary description for Class1.
/// </summary>
public static class WindFormUtilities
{
public static WindFormUtilities()
{
//
// TODO: Add constructor logic here
//
}
public static bool SetComboBoxSelectionError(ComboBox cbo,
ErrorProvider err)
{
}

private bool[] SetComboBoxSelectionError (ComboBox[] cbo,
ErrorProvider err)
{
}

}
}
Nov 15 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
Just make a regular class and make the methods (only) static. All data used
int her methods will also have to be declared static.
"Jim Heavey" <Ji*******@nospam.com> wrote in message
news:Xn*********************************@207.46.24 8.16...
Hello, hoping you can clear up a little bit of confusion that I have on
creating/using static methods.

I want to create a class which hold all my "Utility Methods" for windows
forms. So I created a new project and added that project to my existing
project. The project "type" I selected was a "Class Library". What
this a correct choice.

So if I want to create "Static" methods, does the class itself have to
be static? There is no real reason to instatiate the class, so I am
guessing that I should make the class static. When I attempt to do
this, it tells me the modifier is not valid for this item. Have I got
the wrong format, or the wrong idea? Here is my code...

namespace WindowFormsUtilities
{
/// <summary>
/// Summary description for Class1.
/// </summary>
public static class WindFormUtilities
{
public static WindFormUtilities()
{
//
// TODO: Add constructor logic here
//
}
public static bool SetComboBoxSelectionError(ComboBox cbo,
ErrorProvider err)
{
}

private bool[] SetComboBoxSelectionError (ComboBox[] cbo,
ErrorProvider err)
{
}

}
}

Nov 15 '05 #2

P: n/a
A class Library project is the correct project type, and no, you can't
create a static class. The general rule if you are creating a class that
has all static methods is to make it sealed, since deriving from the class
wouldn't gain anything, and to declare a private default constructor so no
one can create an instance of you class.
"Jim Heavey" <Ji*******@nospam.com> wrote in message
news:Xn*********************************@207.46.24 8.16...
Hello, hoping you can clear up a little bit of confusion that I have on
creating/using static methods.

I want to create a class which hold all my "Utility Methods" for windows
forms. So I created a new project and added that project to my existing
project. The project "type" I selected was a "Class Library". What
this a correct choice.

So if I want to create "Static" methods, does the class itself have to
be static? There is no real reason to instatiate the class, so I am
guessing that I should make the class static. When I attempt to do
this, it tells me the modifier is not valid for this item. Have I got
the wrong format, or the wrong idea? Here is my code...

namespace WindowFormsUtilities
{
/// <summary>
/// Summary description for Class1.
/// </summary>
public static class WindFormUtilities
{
public static WindFormUtilities()
{
//
// TODO: Add constructor logic here
//
}
public static bool SetComboBoxSelectionError(ComboBox cbo,
ErrorProvider err)
{
}

private bool[] SetComboBoxSelectionError (ComboBox[] cbo,
ErrorProvider err)
{
}

}
}

Nov 15 '05 #3

P: n/a
Jim,
So if I want to create "Static" methods, does the class itself have to
be static? There is no real reason to instatiate the class, so I am
guessing that I should make the class static. When I attempt to do
this, it tells me the modifier is not valid for this item. Have I got
the wrong format, or the wrong idea? Here is my code...


Unless you're using the Whidbey version of C#, there's no such thing
as a static class. You can make it abstract or add a private
constructor to prevent it from being instantiated.

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
Nov 15 '05 #4

P: n/a
n!
> So if I want to create "Static" methods, does the class itself have to
be static? There is no real reason to instatiate the class, so I am
guessing that I should make the class static. When I attempt to do
this, it tells me the modifier is not valid for this item. Have I got
the wrong format, or the wrong idea? Here is my code...


I generally make classes with only static members, sealed with a private
constructor. Similar to:

public sealed class MyUtilityClass
{
private MyUtilityClass() // Prevent direct instantiation.
{
}
}

The 'sealed' property prevents someone from inheriting the class, the
private constructor prevents someone from creating an instance of the class
:) From reading your mail I think 'sealed' is basically the equivalent of
what you were expecting a 'static' class to be.

n!
Nov 15 '05 #5

P: n/a
n! <nf********@nomailplease.com> wrote:
I generally make classes with only static members, sealed with a private
constructor. Similar to:

public sealed class MyUtilityClass
{
private MyUtilityClass() // Prevent direct instantiation.
{
}
}

The 'sealed' property prevents someone from inheriting the class, the
private constructor prevents someone from creating an instance of the class
:) From reading your mail I think 'sealed' is basically the equivalent of
what you were expecting a 'static' class to be.


There's no real need to make the class sealed as well as only having a
private constructor - just the fact that its only constructor is
private means that you can't inherit from it.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #6

P: n/a
Then why does the compiler permit this combination? Isnt this like havint a
string as a const and static? You cant because it makes no sense, just as
what you say , it makes no sense.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
n! <nf********@nomailplease.com> wrote:
I generally make classes with only static members, sealed with a private
constructor. Similar to:

public sealed class MyUtilityClass
{
private MyUtilityClass() // Prevent direct instantiation.
{
}
}

The 'sealed' property prevents someone from inheriting the class, the
private constructor prevents someone from creating an instance of the class :) From reading your mail I think 'sealed' is basically the equivalent of what you were expecting a 'static' class to be.


There's no real need to make the class sealed as well as only having a
private constructor - just the fact that its only constructor is
private means that you can't inherit from it.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 15 '05 #7

P: n/a
<di********@discussion.microsoft.com> wrote:
Then why does the compiler permit this combination? Isnt this like havint a
string as a const and static? You cant because it makes no sense, just as
what you say , it makes no sense.


I think there's a difference in the level of logical connection there.
It's not that there's anything *syntactically* redundant about there
being a sealed class with only a private constructor, it's only
*semantically* redundant.

It would be reasonable of the compiler to complain, but I don't think
it's particularly necessary for it to do so.

(There's also the fact that the two will end up in different IL - a
class with only private constructors is *effectively* sealed, it isn't
*actually* sealed.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #8

P: n/a
n!
> There's no real need to make the class sealed as well as only having a
private constructor - just the fact that its only constructor is
private means that you can't inherit from it.


That's true, though the private constructor is there to prevent creation of
a class instance rather than prevent inheritance (even though it effectively
does that job as well), and the compile error is more meaningful when trying
to inherit a sealed class rather than a class with private constructors. :)

n!
Nov 15 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.