locked
Interface Re-Implementation on Windows Runtime

    Question

  • Hey Guys,

    I just noticed a weird behavior while trying to compile some code. I just wanted to ask if I am missing something or interface re-implementation is not allowed on Windows Runtime.

    So a simple example:

    public interface IMyInterface
    {
        void MyFirstMethod();
        void MySecondMethod();
    }
    
    public class MyFirstClass : IMyInterface
    {
        void IMyInterface.MyFirstMethod()
        {
            // TODO:
        }
    
        void IMyInterface.MySecondMethod()
        {
            // TODO:
        }
    }
    
    public class MySecondClass : MyFirstClass, IMyInterface
    {
        void IMyInterface.MyFirstMethod()
        {
           // TODO: something else
        }
    }

    This would at worst case scenario would give a compiler error but would compile (I think) on a .net application. (see http://blogs.msdn.com/b/ericlippert/archive/2011/12/08/so-many-interfaces-part-two.aspx  and )

    Is compilation different on windows runtime? Anybody faced the same issue?

    Thanks in advance...


    Can Bilgin
    Blog Samples CompuSight

    Tuesday, December 30, 2014 11:05 AM

All replies

  • This compiles fine for me in VS2013/latest updates.

    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Tuesday, December 30, 2014 1:44 PM
    Moderator
  • Hey Matt,

    Thanks for the quick response... The actual scenario is when I am deriving from StackPanel and trying to re-implement the IScrollSnapPointsInfo. It's giving me an error similar to:

    "error CS4036: Windows Runtime interface 'Windows.UI.Xaml.Controls.Primitives.IScrollSnapPointsInfo' has already been implemented by a base type of 'CubiSoft.Samples.UI.ShowCase.SingleSnapPointStackPanel'. Re-implementation of 'Windows.UI.Xaml.Controls.Primitives.IScrollSnapPointsInfo' is not allowed"

    really not sure, I am tabula-rasa on this.

    thanks again...


    Can Bilgin
    Blog Samples CompuSight

    Tuesday, December 30, 2014 5:27 PM
  • Can you provide a more concrete example?

    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Tuesday, December 30, 2014 8:02 PM
    Moderator
  • For instance, I want to re-implement one of the methods from the info...
        public class DerivedStackPanel : StackPanel, IScrollSnapPointsInfo
        {
            IReadOnlyList<float> IScrollSnapPointsInfo.GetIrregularSnapPoints(Orientation orientation, SnapPointsAlignment alignment)
            {
                System.Diagnostics.Debug.WriteLine("GetIrregularSnapPoints");
                return new List<float> { 80 };
            }
        }


    Can Bilgin
    Blog Samples CompuSight

    Tuesday, December 30, 2014 8:16 PM
  • OK this is a bit confusing to me.  I read through Eric's blog but didn't really follow it all. I am not going to say "yes, WinRT is different than .NET in this respect", because the example you gave in the first post compiled, and I don't have a deep understanding of the compiler in the way that Eric Lippert does.  However, the example you gave looks to be pure .NET, while the override of StackPanel is WinRT, so we have a difference there.

    In the end, you're just looking to use the GetIrregularSnapPoints method, which is already implemented by StackPanel, so I think all you need to do is derive directly from StackPanel.  I am not sure what benefit you would get from declaring that you want to reimplement the IScrollSnapPointsInfo interface since it's already part of StackPanel, and all of the method are public, so you can directly inherit and change their behavior.

    If there's some part of this that I'm getting wrong, please let me know.


    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Wednesday, December 31, 2014 1:58 PM
    Moderator
  • I guess the difference is that the interface in use here is a WinRT interface that is implement by the StackPanel in native code and you are trying to inherit and overwrite it using managed code.

    As soon as you deal with pure .Net code everything works as it always has in .Net (even in a Windows Store App) but when crossing the runtime boundaries an awful lot of what's happening (COM-Marshaling, etc.) is hidden and that can in some cases lead to behavior that is hard to understand without looking under the hood.

    Wednesday, December 31, 2014 3:05 PM
  • guys, thanks for the comments but this does not solve the issue...

    First, the use-case and the reason why someone would wanna do this. In the first example if I want to cast MySecondClass to IMyInterface and call MyFirstMethod, it would act as MySecondClass... But if I were to override (hide) this method in the derived class without reimplementing the interface, it would behave like MyFirstClass implementation.

    This is exactly the reason I would want to reimplement an interface on an existing class. For example, I want a control that behaves like StackPanel but differs in the snap points it provides once placed into a scroll viewer. The only solution is to re-implement the interface.

    @Oliver, I have the same suspicion that we are kind of crossing boundaries here but cannot find any documentation that this cannot be done. If "basics" are supported and this feature is a .net feature and supported in .Net implementations, I would expect it to be treated like a simple inheritance scenario.


    Can Bilgin
    Blog Samples CompuSight


    Friday, January 9, 2015 7:20 AM
  • I've sent a query to our dev guys and will update if/when I hear back.

    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Friday, January 9, 2015 2:25 PM
    Moderator
  • thanks a lot Matt.

    Can Bilgin
    Blog Samples CompuSight

    Friday, January 9, 2015 3:10 PM
  • Hi Can,

    As a guidance/rule any public class in a WinRT component that we develop should be sealed as otherwise one will start extending unmanaged code in managed code. Same guidance should be applicable to anything that is given by Microsoft (controls in this case, which are part of namespace Windows.UI.Xaml in Windows.winmd).

    For immediate resolution I will suggest you create a Windows Runtime component and in that you extend any WinRT control to do what you are trying. I think that will fix your immediate issue, if that does not work then it is truly a bug. 

    For why those controls are not sealed I can understand and think that there is a need of a new keyword in C# to mark classes open to extend as WinRT component i.e. unmanaged but sealed for just .NET managed code :)


    -- Vishal Kaushik --

    Please 'Mark as Answer' if my post answers your question and 'Vote as Helpful' if it helps you. Happy Coding!!!


    Friday, January 9, 2015 6:00 PM
  • For immediate resolution I will suggest you create a Windows Runtime component and in that you extend any WinRT control to do what you are trying. I think that will fix your immediate issue, if that does not work then it is truly a bug. 

    I tried to do so and got same compile time error that you were getting. Which tells me There is a different behavior of inheritance when working between WinRT and .NET; which I kind of understand is due to managed vs unmanaged world. But since this does not work even for WinRT component as well, then it is either a bug in compiler as it does not differentiate between output type of a class library or inheritance fundamentals in WinRT world are little different.

    I will also like to wait for Matt's response now.


    -- Vishal Kaushik --

    Please 'Mark as Answer' if my post answers your question and 'Vote as Helpful' if it helps you. Happy Coding!!!

    Saturday, January 10, 2015 6:32 PM