Is it possible to call a static method in the type class of a generic class?

[steve bull]

I have a class SwatchPanel which takes Swatch as a parameter type. How can I call a static function within the Swatch class?

For example the code below fails on TSwatch.Exists. How can I get the call to work?

Exists is a method within the Swatch class NOT the SwatchPanel class.

Is this possible?
Suggestions would be very welcome.

Thanks,
Steve


public class SwatchPanel<TSw atch> : System.Windows. Forms.Panel where TSwatch : Swatch
{
protected virtual bool SetOkButtonStat e()
{
if (TSwatch.Exists (ColorDescripti on))
do something
}
}

[steve bull]

Thank you for taking up so much of your time to make all these suggestions.

I don't think generics are the natural way of dealing with my problem. The way I originally developed the SwatchPanel as
a series of subclasses worked pretty well where SwatchPanel did most of the work. Thinking about what you have talked
about leads me to believe that the original reason for trying generics might be overcome with some of your suggestions.

Using subclasses only had the problem of passing around a List<Swatch> to the read/write routines which I wanted to be
cast to the swatch type appropriate to those routines. I think that encapsulating the swatchList as you described would
work there as well. What I have also works, it doesn't break any OO rules I don't think and I don't need to retest
everything again.

In fact, using generics, read/write wasn't the only problem I had - just the biggest of them. For example when I draw
the swatches on the panel they could be different sizes depending on the type of swatch and this would be a SwatchPanel
parameter really as I could decide, and have, to write other widgets which have different sizes that they would have the
swatches draw themselves.

Your explanations have been much appreciated.

Thanks,
Steve


On Thu, 8 Dec 2005 18:05:29 -0000, Jon Skeet [C# MVP] <sk***@pobox.co m> wrote:

steve bull <bu****@comcast .net> wrote:

>Indeed. And that would be a bad way of writing it, IMO. It looks like
>you want polymorphism at that stage - either have a class which
>encapsulates a list of Swatches (generically) and override the
>behaviour appropriately, or have one Write method which uses
>polymorphism on the Swatch class to work out how to write each entry.

the problem with this suggestion is that it just pushes the problem
down a level. e.g. if I encapsulated the swatchList as
SwatchList<TSwa tch> and call swatchList.Writ e() I would still need to
get some constant information associated with that swatch type in the
new class. Which is the same problem in a different place.

No, it's not - because then you could ask for *instance* information,
and that could be overridden. If you have ColorSwatchList which extends
SwatchList<Col orSwatch>, that could override appropriate methods to say
what headers to use etc.

>Alternativel y, have an instance method in SwatchPanel which writes its
>list out.

I am not quite sure what you mean here. Do you mean write routines

Write(List<Colo rSwatch) swatchList)
Write(List<Shad eSwatch> swatchList) etc?

Just WriteList(), given that it would already know the list internally.
You wouldn't have different methods - you'd have one method which could
be overridden in classes which needed to.

If so it would seem to me that it would break all the reasons for
using generics in the 1st place.

I still don't see any way forward with this - I seem to be better off
going back to subclassing and using a non-typesafe array. At least it
avoids all these issues even though it is far from ideal.

I would try looking at the problem from scratch, and try to avoid using
overloading as a poor man's form of polymorphism - that's not what it's
there for.