Agora se toda aquela estrutura MXML nada mais é que um esquema para gerar classes ActionScript, então por onde andam esses arquivos que não aparecem nas pastas do projeto?

Criando um novo projeto, que eu vou chamar de “ProjetoFlex” (muito original) e colocamos apenas um label:

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
<mx:Label text="OLÁ MUNDO" /></mx:Label></mx:Application>

No Flex Navigator temos a seguinte estrutura.

Nada em especial, só as pastas de depuração e a de template idênticas, como deveria ser, sendo diferente apenas pelo ProjetoFlex.swf que esta representado pelo ProjetoFlex.mxml.

Vamos fazer com que o Flex não esconda mais os códigos ActionScript clicando com o botão direito do mouse sobre a pasta do projeto.

Abrimos a opção Properties e selecionamos a opção Flex Compiler.

Agora no campo de Addicional compile arguments, orientamos o Flex para que ao compilar os arquivos mostre a pasta de scripts. Para isso basta deixar o campo desta maneira:

-locale en_US -keep-generated-actionscript

Feito isso clique em Apply e depois em OK.

Uma nova pasta chamada generated vai aparecer e nela todos os scripts que o Flex precisou criar para poder chegar ao seu resultado final o SWF.

Aos curiosos é uma boa fonte de informação para entender melhor como o Flex monta o seu resultado final, podendo até nos levar a fazer o script manualmente do que utilizar a tag de programação do Flex para melhorar o desempenho do projeto.

E esta pasta não se aplica somente a página principal, se aplica a tudo desde seus componentes personalizados, até mesmo o CSS. Supondo que você crie sub-pastas para organizar sua estrutura, por exemplo um a pasta só para CSS, dentro dela será criada uma pasta generated correspondente a este conteúdo.

System.useCodePage = true;

Que bom, de repente seu problemas acabaram, todos aqueles caracteres começaram a funciona, mas que comando maravilhoso é esse? Vamos ver o que a Adobe nos diz.

Um valor Booleano que determina qual a página de código a ser usada para interpretar arquivos de texto externos. Quando a propriedade for definida como false, os arquivos de texto externos serão interpretados como Unicode. (Esses arquivos devem ser codificados como Unicode quando você os salva). Quando a propriedade está definida como true, os arquivos de texto externos são interpretados usando a página de código tradicional do sistema operacional que executa o aplicativo. O valor padrão de useCodePage é false.

O texto carregado como arquivo externo (usando a classe Loader.load(), URLLoader ou URLStream) deve ter sido salvo como Unicode para que o aplicativo o reconheça como Unicode. Para codificar arquivos externos como Unicode, salve-os em um aplicativo que ofereça suporte a Unicode, como Bloco de notas do Windows.

Resumindo a história, desde que você mantenha o valor de System.useCodePage como false, o Flash irá interpretar os dados recebido como Unicode, mas também significa que eles serão enviados as páginas dos servidores também como Unicode.

Unicode: é um padrão universal que permite aos computadores representar e manipular de forma consistente praticamente qualquer sistema de escrita que exista.

Então, uma vez que você carrega um arquivo externo que não esteja em Unicode e aparecem aqueles caracteres malucos você corre para mudar o System.useCodePage para  true. Vamos ver agora o que a adobe diz sobre isso.

Quando esse código está presente, o aplicativo interpreta o texto externo usando a página de código tradicional do sistema operacional que executa o sistema operacional. Geralmente, é CP1252 em um sistema operacional Windows em inglês e Shift-JIS em um sistema operacional japonês. Se você definir useCodePage como true, o Flash Player 6 e superior tratarão o texto como o Flash Player 5 o trata. (O Flash Player 5 tratava todos os textos como se estivessem na página de código tradicional do sistema operacional que executava o player).

Quer dizer, seu problema se resolve por que apartir deste momento os textos serão interpretados de acordo dom o sistema operacional que estiver executando o SWF e não mais usando a codificação universal.

Acontece que seu cliente comprou um notebook direto dos Estados Unidos, ou pior ele é Chinês e você vai apresentar seu site pra ele, ai eu te pergunto:

O sistema operacional dele tem os nossos caracteres? Você acha mesmo que ele vai poder ver todos aqueles acentos maravilhosos? Os dados que você vai carregar estão no formato que você precisa?

Então eu recomendo, se você realmente quer que o máximo possíveis de pessoas possam usar perfeitamente o seu site, procure usar o System.useCodePage com valor padrão false.

Por isso, se necessário, procure tratar os dados enviados ou recebidos pelo Flash antes de mudar o tipo de codificação que ele irá trabalhar.

http://help.adobe.com/pt_BR/AS3LCR/Flash_10.0/index.html

Tem também uma orientação para quem quer migrar do AS2 para o AS3 também em português.

http://help.adobe.com/pt_BR/AS3LCR/Flash_10.0/migration.html

Particularmente para aqueles que ainda não aderiram ao AS3 acho que já é um bom momente. Eu mesmo não havia aderia completamente ao AS2 por que o mesmo apresentava varios bugs  que mesmo usando AS2 eu programava como se fosse AS1.

Felizmente o AS3 parece estar funcionado como prometido, já trabalho com ele desde o Flash CS3 e está exelente, é mais rápido e organizado de se trabalhar.

Pode ser que você se lembre do getURL que até o Flash 7 era o nosso meio de comunicação com o navegador antes da chegada do  ExternalInterface ainda no AS2 e que felizmente logo na seqüência,  o getURL saiu de cena para dar lugar ao navigateToURL no AS3.

Passada por esta fase tornou-se obrigatório o uso do ExternalInterface e o navigateToURL foi deixado de lado para o uso exclusivo de acesso a links. Eu até concordaria, desde que todos os pontos fossem cobertos.

Vamos a um exemplo criando dois botões, um usando o  ExternalInterface e outro usando  navigateToURL para executar um JavaScript. Vou utilizar neste exemplo um script para adicionar a favoritos que encontrei no site codigofonte que funciona em vários navegadores.

JavaScript:

function addFav(title,url)
{
	if (window.sidebar)
	{
		window.sidebar.addPanel(title, url,"");
	}
	else if(window.opera && window.print)
	{
		var mbm = document.createElement('a');
		mbm.setAttribute('rel','sidebar');
		mbm.setAttribute('href',url);
		mbm.setAttribute('title',title);
		mbm.click();
	}
	else if(document.all)
	{
		window.external.AddFavorite(url, title);
	}
}

Agora no Flash, fiz dois botões:

Cada um executando o mesmo JavaScript de maneiras diferentes:

ActionScript:

// Importando as classes que vamos utilizar.
import flash.external.ExternalInterface;
import flash.net.navigateToURL;

// Vamos definir o título do favorito.
var titulo:String = "Renato Pacheco";
// Aqui, definimos a url do favorito.
var url:String = "http://www.renatopacheco.com.br";
// Juntando os dois dados acima, montamos um JavaScript covencional.
// Poderiamos usar até em um link de página HTML.
// É muito importante usar a função void(0) para anular o retorno da função qe vamos executar.
var javaScript:String = "javascript:addFav('" + titulo + "','" + url+ "');void(0);";

// Aplicando a um dos botões a função ExternalInterface.
ExtIntBtn.addEventListener(MouseEvent.CLICK,function($e:MouseEvent):void{
	ExternalInterface.call("addFav",titulo,url);
});
// Aplicando ao outro botão o navigateToURL.
NavToUrlBtn.addEventListener(MouseEvent.CLICK,function($e:MouseEvent):void{
	navigateToURL(new URLRequest(javaScript),"_self");
});

Ao colocar o SWF na mesma página que o código JavaScript e clicar em qualquer um dos botões aparentemente temos quase o mesmo resultado:

A primeira vista temos o mesmo resultado, mas não podemos esquecer que esta ação depende do usuário para ser concluída.

No caso do navigateToURL não faz diferença pois o flash continuará sua execução normalmente mas, para o ExternalInterface a história não é bem assim. Quando é executado o ExternalInterface.call() espera um retorno do javascript seja ele nulo ou não, então espere que o usuários demore uns quinze segundos para terminar a ação e veja o que acontece:

Você pode até achar que isso não acontece e que ninguém vai levar mais de quinze segundos para adicionar um link aos favoritos, pois eu lhe digo que já aconteceu e não interessa sua justificativa, o cliente vai entrar em pânico quando vir uma mensagem dessa.

Por isso eu pensaria duas vezes antes de tornar o uso de o ExternalInterface uma regra indiscutível e a prova de falhas.