While we're on the subject of language constructs
-
I ran into a problem that I couldn't see how to solve in C#. I have a method that takes a Control parameter. I wanted to further restrict it so that is only took Control objects that also implemented a particular interface. So I'd like to be able to declare something like:
public interface IMyNotificationsControl : Control
{
void MyNotification1();
void MyNotification2();
}Of course, this fails at compilation, since Control is an object, not an interface. If it were permitted, it would mean that an object of this type would support the entire Control interface (in fact derived from it) but also implement the additional methods. That way, I could declare my function like this:
public void MyFunction(IMyNotificationsControl control)
{
...
}Of course, you could derive a new object type from Control to accomplish this, but in my case, I need to take a wide variety of Control types (e.g. different classes derived from specific controls like TreeView etc. I realise that multiple inheritance would solve this problem. But is there a better way to deal with it in C# other than casting and trusting the programmer? Tom Clement
-
I ran into a problem that I couldn't see how to solve in C#. I have a method that takes a Control parameter. I wanted to further restrict it so that is only took Control objects that also implemented a particular interface. So I'd like to be able to declare something like:
public interface IMyNotificationsControl : Control
{
void MyNotification1();
void MyNotification2();
}Of course, this fails at compilation, since Control is an object, not an interface. If it were permitted, it would mean that an object of this type would support the entire Control interface (in fact derived from it) but also implement the additional methods. That way, I could declare my function like this:
public void MyFunction(IMyNotificationsControl control)
{
...
}Of course, you could derive a new object type from Control to accomplish this, but in my case, I need to take a wide variety of Control types (e.g. different classes derived from specific controls like TreeView etc. I realise that multiple inheritance would solve this problem. But is there a better way to deal with it in C# other than casting and trusting the programmer? Tom Clement
The only way I can see is: public interface IMyNotificationsControl { ... } public void MyFunction(IMyNotificationsControl control) { if( ! ( control is System.Windows.Forms.Control ) ) { throw new Exception( "Must be of type System.Windows.Forms.Control" ); } ... } or public void MyFunction(System.Windows.Forms.Control control) { if( ! ( control is IMyNotificationsControl ) ) { throw new Exception( "Must implement IMyNotificationsControl" ); } ... } sorry, i dont think there is any other way.
-
I ran into a problem that I couldn't see how to solve in C#. I have a method that takes a Control parameter. I wanted to further restrict it so that is only took Control objects that also implemented a particular interface. So I'd like to be able to declare something like:
public interface IMyNotificationsControl : Control
{
void MyNotification1();
void MyNotification2();
}Of course, this fails at compilation, since Control is an object, not an interface. If it were permitted, it would mean that an object of this type would support the entire Control interface (in fact derived from it) but also implement the additional methods. That way, I could declare my function like this:
public void MyFunction(IMyNotificationsControl control)
{
...
}Of course, you could derive a new object type from Control to accomplish this, but in my case, I need to take a wide variety of Control types (e.g. different classes derived from specific controls like TreeView etc. I realise that multiple inheritance would solve this problem. But is there a better way to deal with it in C# other than casting and trusting the programmer? Tom Clement
Unless you create a new abstract class that derives from Control and implements the interface (stubbing out the interface methods as abstract methods), you can't automatically get what you want. You say that you have to handle a wide variety of controls including TreeView, so you will be dealing with Controls that don't implement the interface, correct? If this is the case, your method should do something like this:
public void MyFunction(Control control)
{
IMyNotificationsControl imnc = control as IMyNotificationsControl;if (imnc != null)
{
// You've got a control that implements your interface...
}
}
I, for one, do not think the problem was that the band was down. I think that the problem may have been that there was a Stonehenge monument on the stage that was in danger of being crushed by a dwarf.
-David St. Hubbins -
Unless you create a new abstract class that derives from Control and implements the interface (stubbing out the interface methods as abstract methods), you can't automatically get what you want. You say that you have to handle a wide variety of controls including TreeView, so you will be dealing with Controls that don't implement the interface, correct? If this is the case, your method should do something like this:
public void MyFunction(Control control)
{
IMyNotificationsControl imnc = control as IMyNotificationsControl;if (imnc != null)
{
// You've got a control that implements your interface...
}
}
I, for one, do not think the problem was that the band was down. I think that the problem may have been that there was a Stonehenge monument on the stage that was in danger of being crushed by a dwarf.
-David St. HubbinsThanks for the reply Kentamanos (and krisp). Both solutions are reasonable. I actually used krisps, since I had to fail if the control did not implement the interface. The discussion is really a theoretical one. My point was that I couldn't just derive from Control and include the interface methods, since, for example, I'd need to handle controls derived from both (e.g.) ListView and TreeView. Since I can't insert my new control in the object hierarchy above these two controls, given the single inheritance nature of things in C# I couldn't see the kind of solution I'd really like, which is the ability to declare a Type consisting of a class plus an interface. I guess there could be a restricted interface construct that would provide something more than what C# currently provides but that was less then full multiple interitance. This would be something like: interface IMyInterface RestrictedTo , Oh well... :) Tom
-
Thanks for the reply Kentamanos (and krisp). Both solutions are reasonable. I actually used krisps, since I had to fail if the control did not implement the interface. The discussion is really a theoretical one. My point was that I couldn't just derive from Control and include the interface methods, since, for example, I'd need to handle controls derived from both (e.g.) ListView and TreeView. Since I can't insert my new control in the object hierarchy above these two controls, given the single inheritance nature of things in C# I couldn't see the kind of solution I'd really like, which is the ability to declare a Type consisting of a class plus an interface. I guess there could be a restricted interface construct that would provide something more than what C# currently provides but that was less then full multiple interitance. This would be something like: interface IMyInterface RestrictedTo , Oh well... :) Tom
Another solution could be to have interface with a method that returns Control interface IMyIFace { ... methods ... Control GetControl(); } that way, when you inherit from some control and implement IMyIFace, you will return this in GetControl() method. Then in the methods that accepts IMyIFace, you can get a hold of control by calling GetControl(), and you'll have guarantee that the passed object implements IMyIFace and that it can give you control. Of course, then it's up to the implementator to make sure they return this in GetControl()