To get a Flash™ file (.swf) to work with a CGI file is very important to any interactive site. Without CGI interactions, users can't search databases, enter a chat room, or use a bulletin board.
Unfortunatly, Flash™ is not the friendliest to use interface for interactivity. Unlike HTML form commands such as pull-down menus, radio buttons and check boxes, Flash™ makes you create your own and figure out how to get them to send your variables to your script. The good part about this is that you can be creative in your use of buttons and checkboxes, but if you want to use hundreds of check boxes for different searches on a single scrollable page (as I wanted to), and you have 51 pages like this, it becomes very difficult. It involves writing action script (the Flash™ language) to dynamically read in multiple variable names, then "write" the check box movies to your current movie based on the returned variables from your CGI script. If you only have a few form elements, drawing them and getting them to work isn't too bad though.
Basically, all variables within the movie you have your "submit" button in will be sent to your script using either the GET or POST feature (Flash™ lets you select which one). Variables from your script can be sent back to the Flash™ movie also. Problems quickly arise when you have multiple form buttons, each in the same movie, each posting to the same CGI script, yet only one requires a text entry box. Flash™ doesn't know which one required the text entry box and which ones didn't, so it posts all variables in that movie clip to the script (could lead to problems in the script). To fix this, each button/text box must be put in a new movie clip. Each movie clip should contain it's own URL to interact with your CGI and must be put in the main movie. This allows each button to post only it's variable to a script of your choice. This also allows multiple text entry boxes displayed at the same time to post their contents to different scripts.
Performing simple data transfer to a CGI script is not obvious since the action commands of Flash™ are not as easy to use as the "FORM" HTML tags (there are no tags or dividers between multiple text entry boxes or other button variables in a movie to control which one posts to the script, so each time you want to post unique variables to a script, you must put the button/text entry in its own movie as previously mentioned). Regardless, since Flash™ offers unique effects that Java can not (at least as easily), it is up to us web designers to work around any problems and get our Flash™ to work with CGI.
The main problem that is encountered when trying to post variables to a CGI script from Flash™ is that when the script returns the results, Flash™ has no capability of opening a new movie clip or frame within your original Flash™ movie with the preformatted HTML output from your script. This leads you to make one of two choices. First, you can work around this problem by using cookies, a CGI script specially formatted to output variables that Flash™ can recognize, your original CGI script that outputs HTML, and java to get the HTML output to temporarily replace the Flash™ movie you were viewing with the HTML output from the Flash™ movie. Hitting the back button on the web browser will return you to the previous Flash™ menu. Second, you can use only Flash™ and your CGI script that has been specially modified to send variables in a special "Flash™ format" to Flash™ and get these values to be displayed as text within Flash™. The second choice is used if your scripts do not involve the output of "inline" pictures (pictures that are automatically displayed on the same page as your text results). In the future, perhaps Flash™ programmers could incorporate a text link that is similar to the img src HTML tag that lets you dynamically import pictures from a web server so that Flash™ can more easily display pictures after CGI script variables are returned to it (a similar feature is included in Macromedia™'s Generator™, but this program costs $5000 and only works with a set of server software that you must buy seperatly). So on with the details of how to do this:
First Option:
You could select the "_self" option when posting to the script to make the results come back in the same window as the Flash™ movie you were viewing, but when you hit the back button on the web-browser, you will end up restarting the Flash™ movie. You could get around this problem by using multiple tiny .swf movies, one for an introduction, another for a menu, another for each choice in your menu, but this becomes like writing HTML again, and pages do not flow like they should in Flash™. Although, using style sheets where you change the background at the end of each search as well as changing the background in the same way using Flash™ functions when you start a search could help blend the transition between movies, the movie will never really "flow".
In Flash™, you can use a single .swf file to load multiple .swf files into the main one when you need them. Then, you could display a main .swf file as a menu and another one as a text entry search box, displaying both in the same window at the same time (much like frames in HTML work). Loading multiple .swf movies in the "main" .swf movie and then selecting to use the "_self" option in the text entry search box .swf movie when posting to a script will not work, since the returned values from the script will replace the ENTIRE movie, not just the .swf movie you were playing within your main .swf multi-movie file.
You could use cookies that detect when the user has viewed the main Flash™ intro movie (the .swf file that contains the intro, menu, and search options), then when they hit the back button after viewing the output from the cgi script you automatically forward them to the menu option page of the main .swf file. To do this, you must break up the main .swf file that contains your intro, menu, and options into just the menu and option parts. Using a simple java cookie, if they already viewed the introduction, just don't display it again and go right to the menu. If the time between clicking a menu option and opening the search boxes or options is fast, the user can still navigate through the site using Flash™. There is a better way to make your Flash™ movie remember what page it should display when a user comes back from a search that does not involve increasing the download time of the user (to download the main .swf file, then multiple .swf files later), but is much more complex:
Option A (use java and cookies): You first need to change the cookie variable within Flash™ to reflect the Flash™ menu choice you were posting from through Javascript each time you post or get the results from your cgi-script (basically, make Flash™ rewrite the cookie using java, depending on what search is performed). You will also need to make sure that your main .swf file (the one with the intro, menu, and search options) must look for the contents of the cookie variables (use java to do this) before displaying the introduction of your website. If the cookie variable contains the page identifier that you set as a variable when your user posted to a CGI script, then your main .swf movie opens ONLY that page. If it doesn't find this cookie, or any variables set in the cookie that represent the last page the user used before performing the search, it just displays the introduction again.
Option B (use CGI, Cookies, Java, and a text file in a hidden directory): Send the user a cookie with a random session id using your cgi-scripting skills when they first load the Flash™ movie. Write this session id to a text file on the website somewhere, along with all of the other session-ids of all the people viewing your Flash™ movie. Make sure that your main .swf file (the one with the intro, menu, and search options) looks for the contents of this text file stored on your website that contains the session-id Flash™-formatted variable before displaying the introduction of your website. Each time a user navigates in a Flash™ file to a menu option, then invokes a CGI operation, send the CGI script a variable that represents the page in the Flash™ movie that the user used when invoking that CGI script as well as the user's session ID (that you read into a Flash™ variable using java to read the cookie contents). In the CGI script, using the special "Flash™ variable format", write that information next to their session id in the text file stored on the web server. When the main .swf movie reloads after the user returns from viewing the output from your CGI script, make sure that the Flash™ movie first reads this text file stored on the web server. Then, using action scripting, compare if any of the variables in the the text file match the cookie session-id (you can check this by using java to get the cookies contents into a Flash™ variable). If they match, read the variable next to the session-id in the text file. This variable was written by the CGI script and represents the last Flash™ page viewed before the search or CGI function was performed. If this value exists, and represents the location of a Flash™ menu option search page, then forward the user (within you .swf movie using action scripting) to that search page, otherwise, just play the introduction. If you are feeling really creative, you may want to send the entire navigation of the user through your Flash™ movie, up to the point they left the .swf to the CGI script and then send it back to the Flash™ movie when they go back to the Flash™ movie. Using Flash™ navigation buttons, they can then hit the back buttons you created in your Flash™ environment to follow their original paths.
Second Option:
Basically, Flash™ does not know how to display the standard HTML that your script usually uses, so you must make special modified scripts to work with Flash™. If your script outputs pictures directly or indirectly (indirectly means that it puts the img src="../images/picture.jpg tag somewhere and directly means that it actually "writes" the picture to the output using the content-type header), Flash™ can NOT display it. So don't plan on using Flash™ to output pictures within the results from your search unless you use the First option above or open up a bunch of java-windows outside of your Flash™ movie with your script outputted pictures in them. You can however put http links in place of any of your outputted pictures and use java interactivity to open up a small new window to display a picture in that the user clicked on within the Flash™ movie. Well, enough with the general problems and on with the Flash™ work arounds to get the Flash™ movies to display your special "Flash™ formatted" results without pictures from your scripts (note that Flash™ formatted variables are the same as how the "GET" form action sends it's variables):
In the Flash™ movie, you will post variables to a CGI script that you specifically modified to output in the special Flash™ variable format. When you post or get your variables to the CGI script, just add another variable "Flash™=true" so that your script knows how to format its output. Recall that the standard output of a Flash™ formatted script uses "+" as spaces, "=" to seperate name/value pairs, and "&" to seperate new variables. For example, to get Flash™ to put your CGI results into Flash™ variables, just output from your CGI like this:
$name1 = "myvariable";
$name2 = "notmyvar";
$name3 = "done";
$value1 = "I+like+food";
$value2 = "I+like+learning";
$value3 = "end";
print "content-type: text/html\n\n";
print "$name1=$value1&$name2=$value2&$name3=$value3";
Now, in your Flash™ movie, in the movie that called to your CGI script, these variables were created: myvariable, notmyvar, and done. They have the values I like food, I like learning, and end. Now, you can use your action scripting skills to format the output of these variables as you want. For example, you may want to look for a variable and if it has a paticular value, use another variable as the URL to open a picture or html file in a new javascript pop-up window. Also, if you want a short movie to loop while your CGI script is performing a search, if the variable done=end, then exit from playing that movie and display the results to the user. Note that these variables must be contained within the same movie as the "submit" button you used to call the CGI script. If this script already exists from an HTML based site, it must perform the standard operations of the original HTML POST and GET method from your HTML based site as well as being able to detect an extra variable that you sent from a Flash™ movie that determines if the results will need to output in Flash™ format or standard HTML format. If it is a new script you are creating, then you don't have to worry about formating the output for HTML. Note that in a Flash™ movie, if you have several movies within a scene, or you are using more than one scene (most people would), your Flash™ variables that you send and receive to the CGI script can only be read and evaluated within the movie that invoked the CGI script unless you use a "/" before a movie instance name that the variable is in (for example, to add 1 to the variable called "variable-name" found in the movie called "instance-name" that is a top level movie in the scene you are working in, use "/instance-name:variable-name = Number(/instance-name:variable-name)+1;" for Flash™ 5 variables). In Flash™, first select the load variables into location choice. Then in the URL parameter space, write the path to the CGI script. In the location parameter, enter the name of the movie that is sending and receiving the data to and from the script (e.g., /intromovie or /scene 1). Now, the variables returned from the CGI script will be accessable using Flash™ action scripting. You can display these variables in any way you like, including links to other sites. This is great and easiest to do of the other options I mentioned, but it outputs text-only results.
I put a small and easy to understand .fla help file here to show you how to send your Flash™ variables to CGI using the GET and POST methods. Note that due to a Flash™ 5 problem, when I accidentally updated the Flash™ 4 .fla files here using Flash™ 5, ONLY Flash™ 5 can now open them (Flash™ 5 knows how to read Flash™ 4 files but not save them so Flash™ 4 can open them):
cgi-sample1.swf - Send Variables to CGI - Try the SWF
cgi-sample1.fla - Send Variables to CGI - Get the FLA
cgi-sample2.swf - Return Variables to Flash™ - Try the SWF
cgi-sample2.fla - Return Variables to Flash™ - Get the FLA
Flash™ Bugs and Last Words:
I've personally had the final version of Flash™ 4 crash and close when trying to get it to do some things (such as deleting a movie clip then renaming another movie clip to the deleted movie clip, then working with that movie in the library). It also likes to crash when you try inserting a movie clip with a button in a button inside another button (each button is inserted in the "over" position of the previous button). When testing the movie, on the mouseover of the embedded button it will crash and close. Note that in Win2K, it can crash other applications since Win2k doesn't properly detect the memory Flash™ is using. So when Windows thinks that Flash™ is taking up 6M, the actual program can be taking up 200M and other apps. that try to use the memory that doesn't exist may crash, so I suggest not running Flash™ on your critical web server machines. I am using Windows 2000 Pro. on my development mach. Like all complicated applications, there are certain combonations of user actions that will crash the program. I advise you to continuously save your work!
As far as Flash™ 5 goes, the most important thing to consider is that if you want to try Flash™ 5, so you download it and use it to continue the development of your old Flash™ 4 movies while you try it, after Flash™ 5 expires, Flash™ 4 will no longer read your saved .fla file! This can easily result in a waste of 30 days of work on your old Flash™ movies, since when your trial is up, and you go back to your old Flash™ 4 program, you will not be able to open the file. This unfortunate bug (maybe they just want to make sure you buy Flash™ 5?) has also affected the help files here on my page. I tried to copy the frames in Flash™ 5 and paste them into Flash™ 4 so that I can resave the .fla, but it just won't work. I am forced to manually re-enter all of my code in Flash™ 4 so that people who don't have Flash™ 5 can still open the .fla help files, but for now, the help files in this article will only open in Flash™ 5. I've just tried the new Flash™ 5 plug-in on my old Flash™ 4 movies and I've found a bug there too. In a particular instance of text box entries, using the Flash™ 4 plug-in, the text variable will be blank if it has not yet been set and the user can type in their text into this blank box. However, using the Flash™ 5 plugin, the text field automatically inserts a "[type Function]" in the text box and sets the text box variable to that value. Therefore, you must preset the text variable to "" in the last action script in the frame in the movie before the text box is displayed to make the text box blank for the user. Another problem with Flash™ 5 is that when you make a bunch of changes to your movie, them click the undo button to check something you did previously, if you click on the red timeline frame selector and move it, it will count that as an action and you will loose everything you did because you will not be able to hit the redo button, so save your work before hitting the undo button. Also note that after you use the instance menu to select a symbol and then click the swap symbol button, then click the duplicate symbol button, then select OK without doing a symbol swap right now, after going to the frame with the button you wish to now swap with the button you just duplicated and renamed, the button you just made a copy of does not exist. Flash™ 5 has crashed and closed when editing a broken apart image, using the majic wand, and selecting multiple points using the polygon tool, then hitting ESC on the keyboard. Flash™ 5 actually trapped an error before closing by displaying the pop-up question, "Crashing at gPopupDial should be new!, Yes = go to debugger, No = keep running, Cancel = terminate." and had the title, "I'm crushing your head!". This error was created when I was setting the green color of the special instance effect properties using the slider bar. A program opened up in the background and took focus away from Flash™ while I was still holding the slider and upon reclicking the slider the error came up (I lost a couple hours of work on that one). Another hidden bug in Flash™ 5 occurs when you use Linear or Radial gradient fills. After making a moive play using no fill, the CPU was around 30%. After adding radial or gradient fill to a graphic symbol in the movie, the CPU maxed out. After selecting a solid fill (as it was originally), and retesting, the CPU remains maxed out. I had to restore from a previous saved copy to fix this. The last custom streaming setting will get replaced with the one above it after you close Flash™ 5 and reopen it.
Useful Flash™/Design links:
Lots of Flash™ with Javascript Helpers
Lots of Frame Helpers
Command List for Flash™ Scripting
Javascript 1.2 Commands
Window Manipulation
If you need more help with the above, I'll try to answer your questions: webmaster@pppmail.com and make the subject of your message "Flash Help". If you want to see my latest Flash creation, (12/6/2000) click here and then click the "flash site" link. I will also put up a bulletin board for qustions and answers when I get some more time. I would also like to put an example .fla file and .htm file example on what I talked about above, but this stuff takes time! If you could, let me know what you think of PPPmail.com or CollegeDate.com since I always need feedback on them.
Click Here to see other people's comments/questions
If you need me to make a Flash™ site for you, or help you with your current site, please visit hollywoodnetdesign.net and leave a message there.
Good luck in your Flash™ adventures!