Currently we need to save to Harddisk to transfer pictures between Overlay, Active Picture Object, Picture Manipulator and similar extensions. Because those extensions cannot save to clipboard.
Not sure if it is even possible, but what about an MMF internal virtual drive for that? Not saving to HDD, but to the MMF internal Virtual Drive?
An extension could be made to transfer the image between all of those probably.
Nice idea.
I fully agree with you, it would be a cool improvement.
Actually, it must be possible, and I think - if CT won't implement it in mmf2 - it will be a great feature for mmf3!
EDIT:
Greyhill, how should that work? Could you explain it a bit more specifif, please?
If you know the runtime structure of each of those graphical objects, and know how each one displays its image, then you could create an extension that did something like 'Transer image from Overlay object to Active Picture object'
Ah, I see, okay.
I think you mean like those "Paste into Overlay" functions in some extensions..
well, let's get back to topic.
I don't think about just the graphical objects here, but all objects that needs to transfer data.
Problem with an extension that transfers between specific objects is that it just works for those specific objects. And that wouldn't be the case with an virtual drive. You could load and save anything then
An object could have an expression and an action that returned/did something to a memory address of a graphical surface... or whatever major variable that that object works by..... Then you'd have to have other objects to work with that.
Hope that made some sense... I suppose that's not much different to what i last said.
an extension that allocates a Drive letter and X amount of space to something more like a (Virtual)RAM Drive would be more like it. I mean virtual as in a simulated RAM Drive inside the RAM address of the MMF2 app.
I'd like to try and make something like this if someone could help me learn C/C++. I have a compiler, I just don't understand what any of the code is doing when I look at a source file.
Yes I like this idea, so I spoke up in the topic as I so rarely do.
I like the sound of this a lot, I really dislike saving to the disk at runtime except for when saving and loading files in intentional (i.e. load and save systems).
It wouldn't work as you can't hook into the save functions for different objects.
Posting Permissions
Reply With Quote