The following forum(s) are migrating to a new home on Microsoft Q&A (Preview): Developing Universal Windows apps!

Ask new questions on Microsoft Q&A (Preview).
Interact with existing posts until December 13, 2019, after which content will be closed to all new and existing posts.

Learn More

Generic Class in Application Derived Classes Chain RRS feed

  • Question

  • Anybody know if VS2015 (and probably VS2013) has a problem dealing with a generic class being anywhere in the derive chain of an Application class?

    The following pattern works for pages:

    public sealed partial class MyPage : Class1 {}
    public class Class1 : Class2<MyType> {}
    public class Class2<T> : Class3 {}
    public class Class3 : Page {}
    <local:Class1 x:Class="MyPage" ... >

    As per some MSDN documentation regarding the use of generic classes in XAML, it's typically easiest to hide the generic from XAML by deriving a non-generic class from it and using the non-generic.  So that's what the above does and the pattern has worked repeated for me.

    Then I've tried a few different times to duplicate this pattern for Application using:

    public sealed partial class MyApp : Class1 {}
    public class Class1 : Class2<MyType> {}
    public class Class2<T> : Class3 {}
    public class Class3 : Application {}
    <local:Class1 x:Class="MyApp" ... >

    VS2015 (and I'm pretty sure VS2013) complains about Class1 not existing.  However if I take the Class2<T> out of the chain, VS will accept it.

    So basically I'm trying to find out if I'm fighting a losing battle and VS simply can't tolerate a generic class in the Application derived chain, or if I simply haven't found the right magical incantation yet.

    -- kburgoyne

    Friday, August 21, 2015 5:24 PM

All replies

  • Why you need to do this? What's your main purpose?

    The only expected properties on an Application instance in XAML is the set of elements to populate the Application.Resources property, using a XAML property element usage. For more info, see Resources.

    Best Regards,
    Please remember to mark the replies as answers if they help

    Monday, August 24, 2015 7:18 AM
  • I don't "need" to. I take all the code I find myself repeating over and over again in new projects, and I push it down into a support DLL.  This has been my practice across numerous app architectures.

    App seems like the best place to hold something like settings which are application-wide.  It's best to package those setting into their own class that knows how to save and load itself, perform change notifications, etc.  Those settings (properties) vary from application to application, but the concept of having settings found at the same place within the application structure remains consistent.  When I go to switching between working on different apps, I can find as much commonality as possible.

    Since something like having a settings class instance accessible from the application instance is a repeatable pattern, it would prove useful to move the reference down into a "common" (across applications) Application derived class located in a support DLL.  This brings us to defining a class such as "MyApplication<Tappsettings>" from which the main App class derives, and therefore must be usable with XAML.

    The MAIN issue is really I do not find anything in the MSDN documentation that says this is not permitted, and it is a pattern that DOES work for Page derived classes.  So what I'd like to know, definitively, is whether Visual Studio and/or the XAML compiler actually cannot deal with this construct.  In which case, that fact should be documented in MSDN.  Or whether it is supposed to work and I simply haven't hit upon the magic incantation yet.

    -- kburgoyne

    Monday, August 24, 2015 2:23 PM