If you are having trouble  with Flash files working, or displaying correctly  the HTML wrapper added to your IDX account, you may need to reconfigure your Flash Security settings. For specific details on this issue, please refer to the Cross Domain specific help page at the Adobe Flash support site here: http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html

Many times if you use Dreamweaver to embed the Flash file into your HTML, it can place code that is unneeded. To simplify the embedding, you can use the  code sample below:

<object width="550" height="400">
  <param name="movie" value="somefilename.swf">
  <param name="allowScriptAccess" value="always">
  <embed src="somefilename.swf" width="550" height="400" allowScriptAccess="always"></embed>
</object>

 Replace the values of the parameters in parentheses with value specific to your movie. It is important to note that any links to your SWF file must be absolute, as they reside on a separate server (your server) when the IDX global wrapper is loaded.

 Also of note, the "allowScriptAccess" parameters above are present to allow your SWF file execute any ActionScript code (buttons, etc...) to execute correctly. If you do use the allowScriptAccess parameter please make sure that you trust the SWF file that you are giving access to (if you are the author or completely trust the author of the SWF file).

More information about embedding correctly can be found here:

http://kb2.adobe.com/cps/000/50c1cf38.html

Also, if you are having trouble getting flash to display in I.E. you will need to follow the following link that will help you place some javascript to embed your SWF file:

http://blog.case.edu/webdev/2007/04/19/activex.html

*** From Adobe Flash Help File ***
  Much of Flash Player security is based on thedomain of origin for loaded SWF files, media, and other assets. A SWF file from a specific Internet domain, such as www.example.com, can always access all data from that domain. These assets are put in the same security grouping, known as asecurity sandbox.

For example, a SWF file can load SWF files, bitmaps, audio, text files, and any other asset from its own domain. Also, cross-scripting between two SWF files from the same domain is always permitted, as long as both files are written using ActionScript 3.0.Cross-scripting is the ability of one SWF file to use ActionScript to access the properties, methods, and objects in another SWF file. Cross-scripting is not supported between SWF files written using ActionScript 3.0 and those using previous versions of ActionScript; however, these files can communicate by using the LocalConnection class.

The following basic security rules always apply by default:

 
• Resources in the same security sandbox can always access each other.
 
• SWF files in a remote sandbox can never access local files and data.

Flash Player considers the following to be individualdomains, and sets up individual security sandboxes for each:

 
• http://example.com
 
• http://www.example.com
 
• http://store.example.com
 
• https://www.example.com
 
• http://192.0.34.166

Even if a named domain, such as http://example.com, maps to a specific IP address, such as http://192.0.34.166, Flash Player sets up separate security sandboxes for both.

There are two basic methods that a developer can use to grant a SWF file access to assets from sandboxes other than that of the SWF file:

 
• The Security.allowDomain() method
 
• The cross-domain policy file

The ability of a SWF file to cross-script ActionScript 3.0 SWF files from other domains and to load data from other domains is prohibited by default. It can be granted with a call to the Security.allowDomain() method in the loaded SWF file.