Yes, it’s very useful jules! That’s an approach I’ve been using a lot with ValueTrees (and particularly nicely, with Component properties). It makes it possible to embed data of any kind in existing Components without needing to subclass them (making it quite easy to use dynamic functionality in any type of Component), as well as holding useful data management utilities directly with the pertinent document data. I do currently have to serialise my data manually, as the assert in the implementation stops proceedings at when it hits the custom data. Perhaps it’d be nice to have a bool ‘ignoreDynamicObjects’ flag to optionally bypass that and create Xml without such properties. Not that it’s really any hardship to have my own serialiser (it’s already working fine, and gives me more control anyway).
I was hoping you might consider making it more generic, but I wasn’t sure quite what you’d go for (or if you’d think of it as an ‘approved usage’
Maybe the ValueTree serialization code could do a dynamic_cast downcast to SerializableDynamicObject and if it results in a non zero value call some virtual member doSerialize() ? This way it would still assert for existing users but anyone who wanted to make their custom object serializable could just derive from SerializableDynamicObject instead of DynamicObject and implement the necessary function.
var / Value sounds great then! As long as subclasses of ListBoxModel and TableListBoxModel can produce their own object and return it in response to a row drag, it’s sufficient.
Now how about a way for ListBox and TableListBox models (or derived class) to specify whether dragging to external windows is allowed or not, in the call to dragContainer->startDragging() ?
Hmm, the obvious way to do that would be to add another virtual method to the model class to indicate whether it’s allowed, but that seems rather overkill for such a small feature.
