Click here to Skip to main content
15,886,840 members
Please Sign up or sign in to vote.
4.50/5 (2 votes)
See more:
C#
public interface ICaseStageTransitionControlView : IControlView
{
Button PassButtonToControl { get;set;}
}

namespace Prateep.MSC.Web.Mod.CSE
{
public partial class CaseStageTransitionControl : ICaseStageTransitionControlView
{
 public Button PassButtonToControl
        {
            get { return _button; }
            set { _button = value; }
        }
}


Error	4 'Prateep.MSC.Web.Mod.CSE.CaseStageTransitionControl' does not implement interface member 'Prateep.MSC.Web.Mod.CSE.Views.ICaseStageTransitionControlView.PassButtonToControl 'Prateep.MSC.Web.Mod.CSE.Case.CaseStageTransitionControl.PassButtonToControl' is either static, not public, or has the wrong return type.


I checked 3 times i have no clue whats its complaining any help would be appreciated .
Posted
Updated 25-Nov-11 3:31am
v3
Comments
Timberbird 25-Nov-11 9:20am    
Check property type (Button) in your property declarations. Are these the same? They may come from different namespaces in interface and class
RaisKazi 25-Nov-11 9:29am    
Your code looks OK to me, only problem seems to be with "wrong return type".

The error I see is that you don't define the variable _button in your class declaration.

Try this:
CSS
interface ICaseStageTransitionControlView: IControlView
{
    Button PassButtonToControl { get; set;}
}

public partial class CaseStageTransitionControl : ICaseStageTransitionControlView
{
    public Button PassButtonToControl { get; set; }
}
Discussion: This assumes that you've done the right thing to implement whatever the IControlView interface requires.
 
Share this answer
 
Comments
Sergey Alexandrovich Kryukov 25-Nov-11 22:06pm    
Correct, a 5, but explicit form is better in many cases by several reasons.
I added a sample in my solution, please see.
--SA
RaviRanjanKr 26-Nov-11 3:30am    
Nice Answer, My 5+
MDNadeemAkhter 27-Nov-11 15:06pm    
Nice answer. 5+
In many cases, explicit interface implementation is better then the form shown by Bill:


C#
public interface ICaseStageTransitionControlView : IControlView
{
    Button PassButtonToControl { get; set;}
}

public partial class CaseStageTransitionControl : ICaseStageTransitionControlView
{
    Button ICaseStageTransitionControlView.PassButtonToControl { get; set; }
}


For further detail, please see:
http://msdn.microsoft.com/en-us/library/aa288461%28v=vs.71%29.aspx[^],
http://msdn.microsoft.com/en-us/library/ms173157.aspx[^].

[EDIT]
See also:
http://blogs.msdn.com/b/mhop/archive/2006/12/12/implicit-and-explicit-interface-implementations.aspx[^],
http://adilakhter.wordpress.com/2007/05/02/explicit-interface-implementation-using-c-interface101/[^].

—SA
 
Share this answer
 
v4
Comments
BillWoodruff 26-Nov-11 4:08am    
+5 Your "mind expansions" are always appreciated in the long run, Sergey; I do think it would be valuable, in examples like this, if you gave just one (not necessarily long) example of what explicit implementation enables/improves/clarifies, etc.

And now, I'm off to read the links you cited :)

best, Bill
Sergey Alexandrovich Kryukov 26-Nov-11 19:30pm    
Thank you Bill, I'll think about it. One example is doing a well known trick. How to do this:


class myClass : /* ? */ {
public string this[string index] { get {/*...*/}, set {/*...*/} }
public string this[int index] { get {/*...*/}, set {/*...*/} }
}


Apparently, this is impossible. But you can do it via interface:


interface IIndexed {
public string this[int index] { get, set }
}

class myClass : IIndexed {
public string this[string index] { get {/*...*/}, set {/*...*/} }
string IIndexed.this[int index] { get {/*...*/}, set {/*...*/} }
}


--SA
BillWoodruff 27-Nov-11 12:11pm    
Thanks, SAK, this example, of a type I've frequently seen, essentially accomplishes being able to use identical named Properties, but my "gut reaction" (bias ?) is that while I can understand a programmer having to do this in extending legacy code they cannot change (as a work-around), if this is part of ab origine program design this is bad 'mojo' to have identical named properties. So, what I keep looking for in order to understand the power of using explicit vs. implicit interfaces is the use case "beyond" just "getting away with" using duplicate names. With your help, I'm sure I will locate my "blind spot" in this area :)
Sergey Alexandrovich Kryukov 27-Nov-11 13:03pm    
I've just added a couple of new links with example and some explanations of the usage and benefits.

You see, the change from "public" (implicit) style of declaration of an interface member to the explicit one is not more painful than any other change, only the implementation is no public anymore. If the usage of the method is outside of the class and a compile-time variable is of the class, a compiler can see that the class implements the interface and allows the usage. The real interface-based style of usage is using the interface reference as a compile-time variable, not a reference to the instance of the class, which is a way to interface-based polymorphism, and you also have access through this reference.

Actually, this topic is much deeper. Do you realize that polymorphism based on the interface references for the compile-time type of the member of the collection is very different from the polymorphism based on the base class? Here is why. Structures also can implement interfaces! In this way, same types in a polymorphous containers can be of the types of structures, some can be classes. The level of abstraction is much deeper: one can even mix up reference types (classes) with value types (structures).

Moreover, for interfaces, multiple inheritance is allowed (and it is "design-safe", unlike general case in C++). Hence, the same object can participate in different polymorphous containers with different base types, if the base type is interface and not base class.

--SA
MDNadeemAkhter 27-Nov-11 15:06pm    
5+
Try to implement the members of the IControlView interface too as you have inherited that interface to the current interface.
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900