How do you code a Flash file so that users can manipulate it and save the manipulated version?
June 13, 2004 12:38 PM
This is driving me crazy - how to code a Flash file so that the user can manipulate it and then save the manipulated version?
We've all seen Flash pages where you can do something fun and then save the result, not locally, but to the server (presumably) that the Flash file is on, and then point other people to it, right? I've looked everywhere, asked at the Macromedia forum, etc., and still can't find the answer. Anybody know? Does it require something stronger than ActionScript?
We've all seen Flash pages where you can do something fun and then save the result, not locally, but to the server (presumably) that the Flash file is on, and then point other people to it, right? I've looked everywhere, asked at the Macromedia forum, etc., and still can't find the answer. Anybody know? Does it require something stronger than ActionScript?
Most of the applications that do this are writing the customized data to a local or server-side config file or database, or even containing variables for actionscript in the URL.
The editing process will essentially produce a data object that contains all the configuration choices that the user made (such as strings that they've entered, xy coordinates of movable peices, colors, numbers and types of onscreen symbols, etc). When the viewer calls up the previously edited object, they're telling flash where to find the data object that contains the state of the editing user's choices.
I hope that's clear, soyjoy... the way your question is worded makes it sound like you're trying to actually modify the flash file itself, which is not how this is done.
Here are some slightly dated instructions on passing variables to flash via the URL. This is nice because it's stateless.. you don't need to keep track of any data anywhere. They use the tool to design their thingy, and it gives them a URL which recreates it. That's best for things that have few parameters.
Beyond that, flash remoting is a powerful tool, and pretty easy to use once you get into it. You can even use the outstanding AMFPHP to write server-side PHP functions that can be called from within your actionscript, and retrieve complex data objects from a MySQL (or whatever) database without the need parsing.
On preview, there are ways to use Flash's data cache to effectively allow saving to the local hard drive. I don't know exactly what tools are used to make it happen, but I know that Defend Your Castle can do it.
posted by ulotrichous at 1:52 PM on June 13, 2004
The editing process will essentially produce a data object that contains all the configuration choices that the user made (such as strings that they've entered, xy coordinates of movable peices, colors, numbers and types of onscreen symbols, etc). When the viewer calls up the previously edited object, they're telling flash where to find the data object that contains the state of the editing user's choices.
I hope that's clear, soyjoy... the way your question is worded makes it sound like you're trying to actually modify the flash file itself, which is not how this is done.
Here are some slightly dated instructions on passing variables to flash via the URL. This is nice because it's stateless.. you don't need to keep track of any data anywhere. They use the tool to design their thingy, and it gives them a URL which recreates it. That's best for things that have few parameters.
Beyond that, flash remoting is a powerful tool, and pretty easy to use once you get into it. You can even use the outstanding AMFPHP to write server-side PHP functions that can be called from within your actionscript, and retrieve complex data objects from a MySQL (or whatever) database without the need parsing.
On preview, there are ways to use Flash's data cache to effectively allow saving to the local hard drive. I don't know exactly what tools are used to make it happen, but I know that Defend Your Castle can do it.
posted by ulotrichous at 1:52 PM on June 13, 2004
Thanks, Danelope and ulotrichous. I should have specified one thing: I don't care about saving the Flash file as Flash. Saving it as a bitmap would be fine. A screenshot would workfor this, except the size of the Flash file is wider than the screen.
posted by soyjoy at 5:04 PM on June 13, 2004
posted by soyjoy at 5:04 PM on June 13, 2004
Oh, well you could try this (click on the second O in the logo and choose flash > bitmap creator) but it's a colossal hack, not really what actionscript is meant to do, and sounds like it's dog slow for tiny images, let alone something larger than the screen.
Passing variables to flash to describe what the user has done is really the only way you could pull this off, unless you're willing to rely on the user's smarts and use Flash's printing system to have them print to a file of some sort... and that is not very reliable.
posted by ulotrichous at 7:05 PM on June 13, 2004
Passing variables to flash to describe what the user has done is really the only way you could pull this off, unless you're willing to rely on the user's smarts and use Flash's printing system to have them print to a file of some sort... and that is not very reliable.
posted by ulotrichous at 7:05 PM on June 13, 2004
To save a variable on your user's computer without mucking about with databases or special servers, use SharedObject.
From "Actionscript for flash; the definitive guide":
To create a new local SharedObject, we use the getLocal( ) method, which takes the name of the SharedObject to create as an parameter:
player1Info_so = SharedObject.getLocal("player1");
If a SharedObject by the specified name ("player1") already exists for the current movie, this code retrieves it from the local filesystem; if no such object exists, the Player creates it. Note the use of the suffix "_so"; this is Macromedia's official SharedObject suffix, which will enable code hinting in future versions of Flash.
After our shared object is created (or retrieved), we can add information to it by assigning custom properties to the built-in data property, such as:
player1Info_so.data.highScore = 1200;
Once saved, the SharedObject can be retrieved later with the getLocal( ) method, exactly as it was created:
// Load the SharedObject we created earlier
player1Info_so = SharedObject.getLocal("player1");
posted by signal at 7:31 PM on June 13, 2004
From "Actionscript for flash; the definitive guide":
To create a new local SharedObject, we use the getLocal( ) method, which takes the name of the SharedObject to create as an parameter:
player1Info_so = SharedObject.getLocal("player1");
If a SharedObject by the specified name ("player1") already exists for the current movie, this code retrieves it from the local filesystem; if no such object exists, the Player creates it. Note the use of the suffix "_so"; this is Macromedia's official SharedObject suffix, which will enable code hinting in future versions of Flash.
After our shared object is created (or retrieved), we can add information to it by assigning custom properties to the built-in data property, such as:
player1Info_so.data.highScore = 1200;
Once saved, the SharedObject can be retrieved later with the getLocal( ) method, exactly as it was created:
// Load the SharedObject we created earlier
player1Info_so = SharedObject.getLocal("player1");
posted by signal at 7:31 PM on June 13, 2004
And just in case it's not clear, and despite what everybody's said, these variables are saved locally, as a file on the client's computers.
posted by signal at 8:05 PM on June 13, 2004
posted by signal at 8:05 PM on June 13, 2004
despite what everybody's said, these variables are saved locally, as a file on the client's computers.
But this is temporary data stored within Flash's own local cache, which is rather similar to a browser storing a cookie. To the best of my knowledge, Flash cannot save files outside of that cache, particularly with distinct filenames (i.e. c:\windows\explorer.exe, screencap.bmp, or so on.)
The demo that ulotrichous linked to above is still relying upon server-side scripting (in this case, ASP) to process and serve the image itself. Flash is just passing it the data to store.
posted by Danelope at 11:14 PM on June 13, 2004
But this is temporary data stored within Flash's own local cache, which is rather similar to a browser storing a cookie. To the best of my knowledge, Flash cannot save files outside of that cache, particularly with distinct filenames (i.e. c:\windows\explorer.exe, screencap.bmp, or so on.)
The demo that ulotrichous linked to above is still relying upon server-side scripting (in this case, ASP) to process and serve the image itself. Flash is just passing it the data to store.
posted by Danelope at 11:14 PM on June 13, 2004
Thanks, all. That fotios site is cool, but as you said, not very promising for something this size. SharedObject does look somewhat helpful, but it still doesn't get the last step of making the info publicly available, and I don't want to ask the users to jump through a bunch of hoops to dig it out of their hard drives to send off somewhere.
If anyone's still around, let me ask this: Is there any way to simply zoom out when the manipulating is done, so that the whole image will fit on the screen?
posted by soyjoy at 6:41 AM on June 14, 2004
If anyone's still around, let me ask this: Is there any way to simply zoom out when the manipulating is done, so that the whole image will fit on the screen?
posted by soyjoy at 6:41 AM on June 14, 2004
Well, duh. Right-clicking and selecting "Print" does that. I assumed it was only gonna print the screen. OK, that's something, anyway. Thanks for everybody's patience. At least this is a fallback if nothing else works.
posted by soyjoy at 7:06 AM on June 14, 2004
posted by soyjoy at 7:06 AM on June 14, 2004
This thread is closed to new comments.
The vast majority of Flash apps you describe rely on using Web service calls to databases and/or other server-side scripts to store information for later retrieval. Actually inserting data into a SWF itself (which would then be served via other means) is a hefty undertaking, though it can be accomplished.
(Full disclosure: I work for a company whose primary business involves doing just that.)
posted by Danelope at 1:39 PM on June 13, 2004