If your existing script is written for Flash 6 or earlier, but you want to release the Flash 7 player, you may need to modify your scripts so that they meet the requirements of Flash 7 player and work according to design ideas. Here we will introduce the relevant knowledge.
Flash Player 7 supports more action script commands than previous Flash players, and you can use these commands to write more robust scripts. However, if you use these commands in an existing script and publish the script for the Flash 7 player, it may not work correctly. For example, if you have a script that has a function name that uses error, the script may compile correctly, but not in the way of the Flash 7 player, because the error is a built-in class in the current Action scripting language (therefore, error is a reserved word). You can modify the script to change the name of the error function to a different name, such as errorcondition.
Flash 7 Players also have many changes that affect how a SWF file accesses another SWF file, how to load external data, and how to access local settings and data (such as privacy settings and locally permanently shared objects). Finally, some of the existing features have changed.
If your existing script is written for Flash 6 or earlier, but you want to release the Flash 7 player, you may need to modify your scripts so that they meet the requirements of Flash 7 player and work according to design ideas. Here we will introduce the relevant knowledge.
First, comply with the ECMA-262 Edition 4 plan
Flash 7 player has made some changes to make it more in line with the ECMA-262 Edition 4 program. In Action scripting language 2.0, in addition to the use of class-based programming techniques, additional features are added and certain behaviors have been modified. When you publish and use Action scripting Language 2.0 for Flash 7 players, you can not assign one object type to another. These features do not require you to update existing scripts, but if you publish your scripts for Flash 7 players, you can use these features and then continue to revise and refine them.
Unlike the changes mentioned above, the changes listed in the following table (and some of which are not fully compliant with the ECMA scenario) may cause the execution of existing scripts to be different from the previous results. If you use these features in existing scripts that are published for Flash 7 players, check out these changes to make sure your code runs as designed or if you need to rewrite the code. In particular, the results of calculating undefined (undefined) items are different in some cases, and you should initialize all the variables in a script that is published for Flash 7 players.
SWF file published for Flash 7 player |
SWF files published for early flash players |
Supports case-sensitive (only variable names with different capitalization are interpreted as different variables). This change also affects the files loaded with the #include directive and external variables that are loaded using the Loadvars.load () command. |
Case-insensitive (only variable names with different capitalization are interpreted as the same variable). |
|
|
The result of calculating the return of a undefined item in a numeric context is Nan. |
The result of calculating the return of a undefined item in a numeric context is 0. |
Mycount +=1; Trace (mycount); NaN |
Mycount +=1; Trace (mycount); 1 |
|
|
When the undefined item is converted to a string, the result is undefined. |
When the undefined item is converted to a string, the result is "" (an empty string). |
FirstName = "Joan"; LastName = "Flender"; Trace (FirstName + middlename + lastname); Joan Undefinedflender |
FirstName = "Joan"; LastName = "Flender"; Trace (FirstName + middlename + lastname); Joan Flender |
|
|
When a string is converted to a logical value, if the length of the string is >0, the result is true, and if the string is empty, the result is false. |
When a string is converted to a logical value, it is first converted to a numeric value, or False if the value is not 0, the result is true. |
When you set the length of an array, only valid numeric strings are available to set the length. For example, "6" works, but "6" or "6xyz" does not work. |
When you set the length of an array, even a malformed numeric string can be set to a length: |
My_array=new Array (); my_array["6"] = "x"; Trace (my_array.length); 0 my_array["6xyz"] = "x"; Trace (my_array.length); 0 my_array["6"] = "x"; Trace (my_array.length); 7 |
My_array=new Array (); my_array["6"] = "x"; Trace (my_array.length); 7 my_array["6xyz"] = "x"; Trace (my_array.length); 7 my_array["6"] = "x"; Trace (my_array.length); 7 |
Rules of domain name for setting and local data
In Flash 6 players, when you access local settings (such as a camcorder or microphone access License) or local persistent data (shared objects), the superscope matching rule is used by default. That is, the settings and data for the SWF files stored in here.xyz.com, there.xyz.com, and xyz.com are shared and stored in xyz.com.
In the Flash 7 player, the exact field matching rule is used by default. That is, the settings and data of the files stored in the here.xyz.com are stored in the here.xyz.com, the settings of the files stored in there.xyz.com and the data stored in there.xyz.com, and so on.
The new attribute system.exactsettings lets you specify which rule to use. This property supports files that are published for Flash 6 or later. For files published for Flash 6 players, the default value for this property is false, which means using a hyper-domain matching rule. For files published for Flash 7 players, the default value for this property is true, which means that exact field matching rules are used.
If you use settings and permanent local data and you want to publish a SWF file for Flash 6 players for the Flash 7 player, you may need to set this property value to False in the published file.
Cross-domain and subdomain access between SWF files
When you develop a series of SWF files that communicate with each other, for example, when you use the Loadmovie (), Movieclip.loadmovie (), Moviecliploader.loadclip () command, or a local connection object, You may have these animated files stored in different domains or in different subdomains of a domain.
There are no restrictions on cross-domain or subdomain access in files published for Flash 5 or earlier.
In files published for Flash 6 players, you can use the Localconnection.allowdomain event handler or the System.security.allowDomain () method to specify that Cross-domain access be allowed (for example, let someothersite.com domain files Access files in the somesite.com domain, and there is no need to use commands to allow subdomain access (for example, files in store.someSite.com subdomains can access files in www.someSite.com subdomains).
In files published for Flash 7 players, access between SWF files differs from previous versions in two different ways. First, the Flash 7 player performs an exact field match rather than a hyper-domain matching rule. Therefore, the files that are accessed (even files that are published for earlier flash player versions than Flash 7 players) must be explicitly specified to allow Cross-domain or child domain access. Second, files that are stored in a security protocol (HTTPS) site must explicitly specify access to files that are allowed from sites that use unsecured protocol (HTTP or FTP).
Because the Flash 7 player performs an exact field match rather than a hyper-domain matching rule, you may need to modify these scripts if you want to have access to your existing scripts for the files released by the Flash 7 Viewer. (You can still publish the modified file for the Flash 6 player.) )
If you use the Localconnection.allowdomain () or System.security.allowDomain () statement in the file and specify that access to the Hyper-domain site is allowed, you must modify your parameters to specify the exact domain. The following code illustrates the modifications you may need to make:
Allow SWF file access System.security.allowDomain ("somesite.com") that resides in the www.someSite.com or store.someSite.com domain; Flash 6 player Command My_lc.allowdomain = function (Sendingdomain) {return (sendingdomain==) in a SWF file in the www.anyOldSite.com domain Somesite.com ");} Allow the corresponding command System.security.allowDomain ("www.someSite.com", "store.someSite.com") for SWF file access issued for Flash 7 players; My_ Lc.allowdomain = function (Sendingdomain) {return (sendingdomain== "www.someSite.com | | sendingdomain==" Store.someSite.com ");}
If you are not currently using these statements, you may also need to add such statements.
For example, if your SWF file is stored in the www.someSite.com domain and you want to allow access to SWF files that are posted in the store.someSite.com domain for Flash 7 players, you must store the www.someSite.com domain files Add the following statement (you can still publish files stored in www.someSite.com for the Flash 6 player):
System.security.allowDomain ("store.someSite.com"); my_lc.allowdomain = function (Sendingdomain) {return ( sendingdomain== "store.someSite.com");}
In general, if you publish a file for the Flash 7 player and the following conditions are true, you may want to modify your file to add or modify the Allowdomain statement:
① you write a script that spans a SWF file
Use Loadmovie (), Movieclip.loadmovie (), Moviecliploader.loadclip (), or local connection objects.
② the invoked SWF file (any version) is not stored in a site that uses security protocol (HTTPS), or the invoked and invoked SWF file is stored in a site that uses security protocol (HTTPS).
③swf files are not in the same domain
For example, one file is in www.domain.com and the other is store.domain.com.
To do this you need to make the following modifications:
① if the called SWF file is published for the Flash 7 player, include the System.security.allowDomain or Localconnection.allowdomain statements in the called SWF file, and use the exact domain name match.
② if the called SWF file is published for the Flash 6 player, modify the invoked SWF file, add or modify the System.security.allowDomain or Localconnection.allowdomain statement, using exact domain name matching (as shown in the previous code in this section). You can publish modified files for Flash 6 or 7 players.
③ if the called SWF file is published for Flash 5 or a previous version of the player, the called SWF file is published for the Flash 6 or 7 player, adding system.security. Allowdomain statement, using exact domain name matching (as shown in the previous code in this section). (Flash 5 and previous player versions do not support local connection objects.) )
Iv. access from HTTP to HTTPS protocol between SWF files
As discussed in the previous section, rules for access across domains and subdomains have been modified in the Flash 7 viewer. In addition to performing the exact domain matching rules now, you must explicitly specify that files that are allowed to reside on sites that use the security protocol (HTTPS) are stored in a site that uses an unsecured protocol. Depending on whether the file being invoked is for Flash 7 player or Flash 6 player, you must execute a allowdomain statement, or use a new Localconnection.allowinsecuredomain event handler or System.security.allowInsecureDomain () statement.
Warning: Executing the allowinsecuredomain () statement endangers the security provided by the HTTPS protocol. Make this change only if you cannot rearrange your site so that all SWF files can accept the HTTPS protocol service.
The following code illustrates the changes you may need to make:
Allow storage of SWF file access in http://www.someSite.com or http://www.someOtherSite.com//for Flash 7 players in https://www.someSite.com Command My_lc.allowdomain = function (Sendingdomain) {return (sendingdomain== "someothersite.com") in SWF files published for Flash 6 players; Allow//For Flash 7 player////http://www.someSite.com/http://www.someOtherSite.com for Flash 7 Player issued SWF file access to the corresponding command System.security.allowInsecureDomain ("www.someSite.com", "www.someOtherSite.com"); my_ Lc.allowinsecuredomain = function (Sendingdomain) {return (sendingdomain== "www.someSite.com | | sendingdomain==" Www.someOtherSite.com ");}
If you are not currently using these statements, you may also need to add such statements.
Even if two files are in the same domain, you may need to modify them (for example, http://www.domain.com file calls are stored in https://www.domain.com files).
In general, if you publish a file for the Flash 7 player and the following conditions are true, you may want to modify your file to add or modify the statement:
① you write a script that spans a SWF file (using Loadmovie (), Movieclip.loadmovie (), Moviecliploader.loadclip (), or local connection object).
The ② call file is not stored in sites using the HTTPS protocol and the called SWF file is stored in a site using security protocol (HTTPS).
You must make the following modifications:
① if the called SWF file is published for the Flash 7 player, the called SWF file contains System.security.allowDomain or Localconnection.allowdomain statement, using exact domain name matching (as shown in the code example earlier in this section). This statement is required even if the invoked SWF file is stored in the same domain.
② If the invoked SWF file is published for Flash 6 or a previous version of the player, the invoked and invoked files are stored in the same domain (for example, the file call that holds http://www.domain.com is stored in the https:// www.domain.com files) and does not need to be modified.
③ If the invoked SWF file is published for the Flash 6 player version, the invoked and invoked file is not in the same domain, and you do not want to export the called file against the Flash 7 player, you need to modify the called file, add or modify System.security.allowDomain or Localconnection.allowdomain statements, using exact domain name matching (as shown in the code example earlier in this section).
④ if the called SWF file is published for the Flash 6 player version and you want to publish the called File against the Flash 7 player, include System in the called file. Security.allowdomain or Localconnection.allowdomain statements, using exact domain name matching (as shown in the code example earlier in this section). This statement is required even if all two files are stored in the same domain.
⑤ if the called SWF file is published for Flash 5 or previous player versions, and two files are not in the same domain, you can do two things. You can publish the called file or modify the System.security.allowDomain statement for the Flash 6 player, using the exact domain name match (as shown in the previous code in this section), or you can publish the called file for the Flash 7 player. Use exact domain name matching (as shown in the code example earlier in this section).
V. Server-side policy files that allow access to data
Using these data mount calls, flash documents can load data from external sources: Xml.load (), Xml.sendandload (), Loadvars.load (), Loadvars. Sendandload (), Loadvariables (), Loadvariablesnum (), Movieclip.loadvariables (), Xmlsocket.connect (), and Macromedia Flash Remoting (netservices.creategatewayconnection). The SWF file can also import resources defined in the Runtime shared library (RSL) or other SWF files at run time. By default, the imported data or RSL must be stored in the same domain as the SWF file that loads the external data or media.
To enable SWF files from different domains to work with resources in the data and runtime shared libraries, you should use a Cross-domain policy file. A cross-domain policy file is an XML file that provides a way for the server to indicate that its data and documents are available to SWF files from certain domains or all domains. Any SWF file from the domain specified in the Server policy file allows access to the server's data or RSL.
If you are loading external data, you should also create a policy file even if you do not intend to release any files for the Flash 7 player. If you are using RSL, and you are publishing the invoked and invoked files for the Flash 7 player, you should create a policy file.