@ChaseFlorell But if I don't want the ResourceDictionary on a page it means I can't create my own ResourceDictionary as a workaround I did have to add the Resources to a page and Retrieve them.
Background info
I was trying to add Application.Resources to an Mvvmcross application. MvvmCross application relies on you building a MvxApplication (Which doesnt inherit from Application) meaning you do not have an Application.Resources property for your application (Can't put them in the App.xaml class)
You can however use Xamarin.Forms.Application.Current.Resources = new MyResourceDictionary();
But you can't create your own Xaml resource dictionary because it is a Sealed class.
What I infact had to do was create a dummy ContentPage with Resources as you have shown and do a for loop on the Resources adding them to my own Resource Dictionary..
Was just wondering whether there was any valid reason as to why it was a Sealed class
I understand your dilemma now (it wasn't clear in the original question). I too tried the same thing and hit a wall. I simply wanted to create a ResourceDictionary.xaml page... and you're right, we cannot.
I do know from a number of months ago that the X.F team wants to un-seal the majority of the API, but they will only do so when they feel it's in a finished state, which makes sense.
I'm not sure if I'd throw it up on Bugzilla, but definitely on UserVoice.
I think you're mixing up some terms here. In C# sealed just means you can't create subclasses. It doesn't mean you can't create instances using the constructor. As long as the type has a public constructor (which this one does) you can create instances of it using new, and then you can add things to it. You can also create one in XAML anywhere that a ResourceDictionary is supported. I even just tested making a new class that has a Styles property of type ResourceDictionary, and I created that ResourceDictionary within a XAML file. All of that works. So what specifically are you trying that doesn't work?
public class MyStyles : ResourceDictionary
{
public MyStyles() { }
}
Which isn't allowed due to the fact ResourceDictionary is sealed. My question is WHY is this class sealed. I see no logical reason as to why you would label this class as sealed
But maybe creating another class with a ResourceDictionary property rather than inheriting is a better idea
The custom class isn't accomplishing anything for that use case. You're just describing having multiple instances of resource dictionaries that you can merge together. The feature you're missing for that is merged resource dictionaries, which WPF and other Microsoft XAML variants have but Xamarin.Forms doesn't.
Even if you could make a custom subclass this XAML syntax wouldn't work:
Because the Application.Resources property is a singleResourceDictionary, and it would throw an exception if you try to put multiple objects in that property. The way it would need to work using merged resource dictionaries is like this:
Again, none of that requires custom subclasses of ResourceDictionary, but it does require the MergedDictionaries property to exist.
Sadly, Xamarin developers have said they have no plans to support that. I just created this UserVoice topic for it so you can go vote for that and encourage others to do so.
Ah, I hadn't looked that deeply at The Resources vs ResourceDictionary bit (and have actually never done pure MS Xaml before)... but you're right. I can't vote on your UV, but I did comment.
That would be great. Be pretty easy to implement that functionality. You'd just have to create a class add the MergedDictionaries collection property, inherit from ResourceDictionary and .....
However this still wouldn't fix the ops issue since he doesn't have an Application.Resources
Again, none of that requires a custom subclass. I can't think of any use cases for custom subclasses of ResourceDictionary, especially not the ones given in this thread. Merged resource dictionaries are the way to support composable XAML resources in every other XAML framework. They're very powerful.
I suppose that's a fair point, but it would still be mooted if you already had that feature, which was the premise I was starting with when I said I couldn't think of a use case. So can you think of any other use cases?
The fact is that there is some advantage to not having to worry about subclasses. It might be cheaper for them to give us the one feature we actually need than to unseal the class and try to handle all the other possible cases. Personally I would much prefer that they implement merged dictionaries as a first class concept rather than the community having to do it.
Answers
On your page, you'll do something like.
Similarily, you can do it at the application level and share it with all your pages.
app.xaml
somepage.xaml
@ChaseFlorell But if I don't want the
ResourceDictionary
on a page it means I can't create my ownResourceDictionary
as a workaround I did have to add theResources
to a page and Retrieve them.Background info
I was trying to add Application.Resources to an Mvvmcross application. MvvmCross application relies on you building a MvxApplication (Which doesnt inherit from Application) meaning you do not have an Application.Resources property for your application (Can't put them in the App.xaml class)
You can however use Xamarin.Forms.Application.Current.Resources = new MyResourceDictionary();
But you can't create your own Xaml resource dictionary because it is a
Sealed
class.What I infact had to do was create a dummy
ContentPage
withResources
as you have shown and do a for loop on theResources
adding them to my ownResource
Dictionary..Was just wondering whether there was any valid reason as to why it was a
Sealed
classI understand your dilemma now (it wasn't clear in the original question). I too tried the same thing and hit a wall. I simply wanted to create a ResourceDictionary.xaml page... and you're right, we cannot.
I do know from a number of months ago that the X.F team wants to un-seal the majority of the API, but they will only do so when they feel it's in a finished state, which makes sense.
I'm not sure if I'd throw it up on Bugzilla, but definitely on UserVoice.
@ChaseFlorell Good Idea, I have added it to UserVoice
https://xamarin.uservoice.com/forums/144858-xamarin-product-suggestions/suggestions/9993753-unseal-resourcedictionary-so-we-can-create-our-own
Voted!
I think you're mixing up some terms here. In C#
sealed
just means you can't create subclasses. It doesn't mean you can't create instances using the constructor. As long as the type has a public constructor (which this one does) you can create instances of it usingnew
, and then you can add things to it. You can also create one in XAML anywhere that aResourceDictionary
is supported. I even just tested making a new class that has aStyles
property of typeResourceDictionary
, and I created thatResourceDictionary
within a XAML file. All of that works. So what specifically are you trying that doesn't work?@adamkemp I understand
C#
but what I was trying to do was:Xaml
Code behind
Which isn't allowed due to the fact
ResourceDictionary
is sealed. My question is WHY is this class sealed. I see no logical reason as to why you would label this class assealed
But maybe creating another class with a
ResourceDictionary
property rather than inheriting is a better ideaMy question is why are you trying to subclass
ResourceDictionary
? What are you adding to it? Why not just do this?I don't understand what problem you are trying to solve by subclassing.
Essentially it would be awesome to be able to add this to the App.xaml
MyColors.xaml
Instead of 300 lines of styles and colors
The custom class isn't accomplishing anything for that use case. You're just describing having multiple instances of resource dictionaries that you can merge together. The feature you're missing for that is merged resource dictionaries, which WPF and other Microsoft XAML variants have but Xamarin.Forms doesn't.
Even if you could make a custom subclass this XAML syntax wouldn't work:
Because the
Application.Resources
property is a singleResourceDictionary
, and it would throw an exception if you try to put multiple objects in that property. The way it would need to work using merged resource dictionaries is like this:Again, none of that requires custom subclasses of
ResourceDictionary
, but it does require theMergedDictionaries
property to exist.Sadly, Xamarin developers have said they have no plans to support that. I just created this UserVoice topic for it so you can go vote for that and encourage others to do so.
Ah, I hadn't looked that deeply at The Resources vs ResourceDictionary bit (and have actually never done pure MS Xaml before)... but you're right. I can't vote on your UV, but I did comment.
That would be great. Be pretty easy to implement that functionality. You'd just have to create a class add the MergedDictionaries collection property, inherit from ResourceDictionary and .....
However this still wouldn't fix the ops issue since he doesn't have an Application.Resources
Would however resolve his issue and of course we could do that in code behind now if
.... wait for it ...
ResourceDictionary wasn't sealed.
ContentPage.Resources = new ResourceDictionary()
would of course work but get us nowhere to read our XAML we'd need to use
ContentPage.Resource = new myResourceDictionary()
or have access to the internal xaml parser so we could.
ContentPage.Resource = XAMLReader.Read("MyColors.xaml");
which to me might be an even better UserVoice Option.
David, if Forms had merged dictionaries then you could do this:
You could also write a XAML file like this (MyCustomResources.xaml):
And then you could reference it the same way:
Again, none of that requires a custom subclass. I can't think of any use cases for custom subclasses of
ResourceDictionary
, especially not the ones given in this thread. Merged resource dictionaries are the way to support composable XAML resources in every other XAML framework. They're very powerful.Valid use Case for Custom Subclass of ResourceDictionary= Implementation of MergedDictionaries.
If ResourceDictionary wasn't sealed you'd have MergedDictiinaries because me,you or any number of coders on the forum would have written it already.
I suppose that's a fair point, but it would still be mooted if you already had that feature, which was the premise I was starting with when I said I couldn't think of a use case. So can you think of any other use cases?
The fact is that there is some advantage to not having to worry about subclasses. It might be cheaper for them to give us the one feature we actually need than to unseal the class and try to handle all the other possible cases. Personally I would much prefer that they implement merged dictionaries as a first class concept rather than the community having to do it.