How do I store an Image in a component (without making a subclass)?


I'm trying to store different images in some components.

The first thing I tried was saving a pointer to the binary image data and its length in the properties (NamedValueSet) of the components. I wanted to use this information to load the image from the static ImageCache with getFromMemory. But I quickly found out that I can't save a pointer in a NamedValueSet.

My second idea was to just store the image itself in the NamedValueSet, but the NamedValueSet doesn't support that either.

My third idea was to add the Images to the ImageCache with addImageToCache and store the hash value (int64) in the NamedValueSet. That did work. But the problem is the ImageCache timeout deletes my Images. So that, too, is not an option.

Is there a canonical way to do what I want to do or do I need to sublass my components just to add the image or will I have to make my own static image cache (I'd probably just use a map)?




There's not really any point in storing an image unless it's in a subclass that actually uses it.. (?)


The point is to use the image in the custom LookAndfeel class.


Ok, that makes more sense!

Well, you can put anything inside a property as a var, which can hold a DynamicObject subclass, but it'd be messy to write. Since you need to explicitly add these images to component instances anyway, probably simplest would be to use a Component subclass that holds the Image, and dynamic_cast in your L+F to see if it's one of those, and to get the image back.


In that case, the best way would be to sublass the LookAndFeel class and store the image there. Just add an Image as a member variable.


I'm probably going to make an interface class with a method that returns the image and dynamic_cast my components to that interface in the L+F class. Thinking about it now, it doesn't seem so bad after all. It's just that I'm reluctant to use inheritance when it looks like there should be a simpler solution and I sometimes think dynamic casting kind of defeats the purpose of polymorphism.

Thanks for the input!




I don't want to put anything related to conrete component instances into my LookAndFeel class.