Thanks Alex. Bitmaps are only an example, here - any kind of derived Asset class suffers from the same issues.
I can understand your comments about CSS skinning etc.; and that the Flex framework is designed for embedding. The particular situation I am working in requires - specifically - that image data in data-driven elements - for example, a TileList - is not from embedded images, but is from runtime-generated images (whether they are bitmaps or not is immaterial - I was using bitmaps as an example). And we are in the process of building a framework that is completely agnostic about where resources come from - from embeds, from external libraries, from user-generated code, from cloning other resources, from ByteArrays fetched across sockets etc. As I'm sure you can see, making that resource framework play nicely with existing (or future) Flex components is very much on the agenda, and we'd prefer not to have to customize existing Flex components (even via ItemRenderers etc.) if we can just use them out of the box. (This is an API which is being handed to other coders, and should therefore be as clean as possible). At the root of it all, I do find it odd that if I have dynamically generated, say, a BitmapAsset (without embedding) that I can't just pass it into a Flex Component at the point at which it needs a BitmapAsset. The trouble is, Flex needs a Class, and all I have is a (perfectly valid) instance. That seems wrong. It seems there should be some way of me being able to go backwards from my instance and find the original class. And there is, of course, but it's useless to just pass a vanilla BitmapAsset class in to Flex because you'll end up with a blank bitmap. Hence my problem. :-) On 10/22/07, Alex Harui <[EMAIL PROTECTED]> wrote: > > Anyway, if you absolutely have to do this, and you know the total > number of different assets you are going to create, you can make different > Bitmap subclasses that clone their bitmap data at instantiation time and > assign the dynamic assets to those Bitmap subclasses. > ------------------------------ > I don't quite get this - could you possibly expand on it further? Thanks, Ian
