Na minha aplicação, tinha a necessidade de adicionar alguns eventos (inicialmente do rato) a um elemento e lidar com os mesmos, muita gente faria, por exemplo ao lidar com 4 eventos do rato numa dataGrid:

[coolcode]
dg.addEventListener(MouseEvent.CLICK, onClick);
dg.addEventListener(MouseEvent.MOUSE_WHEEL onMouseWheel);
dg.addEventListener(MouseEvent.ROLL_OVER, onRollOver);
dg.addEventListener(MouseEvent.ROLL_OUT, onRollOut);
[/coolcode]

O que neste caso teriamos que usar 4 funções diferentes: onClick, onDoubleClick, onRollOver, onRollOut do estilo:
[coolcode]
private function onClick(evt:MouseEvent):void { }
private function onMouseWheel(evt:MouseEvent):void { }
private function onRollOver(evt:MouseEvent):void { }
private function onRollOut(evt:MouseEvent):void { }
[/coolcode]

É facil compreender que muita gente use esta forma (eu já usei), mas existe uma forma mais pratica, uma vez que todos os eventos são MouseEvent, podemos fazer apenas uma função:
[coolcode]
dg.addEventListener(MouseEvent.CLICK, onDGMouse);
dg.addEventListener(MouseEvent.MOUSE_WHEEL, onDGMouse);
dg.addEventListener(MouseEvent.ROLL_OVER, onDGMouse);
dg.addEventListener(MouseEvent.ROLL_OUT, onDGMouse);
[/coolcode]

e construir apenas uma função em vez de 4, fazend o uso de comparação do tipo de evento:
[coolcode]
private function onDGMouse(evt:MouseEvent):void {
switch(evt.type) {
case MouseEvent.CLICK:
trace(“Evento click: “+evt.type);
break;

case MouseEvent.MOUSE_WHEEL:
trace(“Evento roda do rato: “+evt.type);
break;

case MouseEvent.ROLL_OVER:
trace(“Evento Roll Over: “+evt.type);
break;

case MouseEvent.ROLL_OUT:
trace(“Evento Roll Out: “+evt.type);
break;

default:
Alert.show(“Evento detectado, nenhuma função associada!: “+evt.type);
break;
}

}
[/coolcode]

Como podem ver simplificamos o trabalho e ficamos com o código mais organizado, mas ainda podemos alargar esta função a mais eventos, aliás, a todos os eventos do rato, mas não só… se mudarmos a declaração da função de
[coolcode]
private function onDGMouse(evt:MouseEvent)
[/coolcode]
para
[coolcode]
private function onDGMouse(evt:*)
[/coolcode]
A nossa função passa a poder receber qualquer tipo de evento, se bem que nem todos os programadores são de acordo em usar este tipo de função “handler” de multi-eventos, a verdade é que muitas vezes reduzimos o código em dezenas de linhas e o colocamos bem mais legil, ora vejam como além dos eventos do rato, a mesma função passa a poder receber e lidar com DragEvent’s ou DataGridEvent’s:
[coolcode]
private function onDGMouse(evt:*):void {
switch(evt.type) {
case MouseEvent.CLICK:
trace(“Evento click: “+evt.type);
break;

case MouseEvent.MOUSE_WHEEL:
trace(“Evento roda do rato: “+evt.type);
break;

case MouseEvent.ROLL_OVER:
trace(“Evento Roll Over: “+evt.type);
break;

case MouseEvent.ROLL_OUT:
trace(“Evento Roll Out: “+evt.type);
break;

case DataGridEvent.COLUMN_STRETCH:
trace(“Evento DG :”+evt.type);
break;

case DragEvent.DRAG_ENTER:
trace(“Evento DRAG :”+evt.type);
break;

default:
Alert.show(“Evento “+evt.type+”detectado, nenhuma instrução associada!: “);
break;
}

}
[/coolcode]
Neste momento podemos dizer que esta função é valida para lidar com quase qualquer evento, vejam 3 eventos completamente diferentes a usarem a mesma função de “event handle”:
[coolcode]
dg.addEventListener(MouseEvent.CLICK, onDGMouse);
dg.addEventListener(DataGridEvent.COLUMN_STRETCH, onDGMouse);
dg.addEventListener(DragEvent.DRAG_ENTER, onDGMouse);
[/coolcode]

Como devem imaginar, pode ser, e é, muito util!!

Abraço.

#2 – Try, Catch & Finally

É precisamente prevenir as malditas janelas de erro (quando o utilizador têm o flash player debug) e disparar acções quando esse erro acontecer, impedindo assim uma falha na aplicação. Este uso é muito util, embora pessoalmente não o use sempre (iria expandir em muito as linhas de código da aplicação) mas uso sempre que exista uma grande possibilidade de erro, no meu exemplo a seguir verão que é muito util.

O que eu necessitava na minha aplicação, era que quando o utilizador fizer logout (apresentasse o ecra de login de novo) da aplicação todas os meus popup’s adicionados via PopUpManager (podem ser até 20 paineis em popup) sejam removidos. 

Como eu não queria ter a necessidade de estar a controlar individualmente se um painel está aberto ou não (poderia fazer isso atravez de um array de estados) apenas percorro todos os child’s do systemManger na minha aplicação (um popUpManager.addItem() adiciona o popUp à display list do sistemManager, como se tratasse de uma janela) e tento remove-los com o popUpManager. Claro que se a minha aplicação tiver um elemento que não tenha sido colocado pelo PopUpManager iria acontecer um erro ao tentar remover esse componente, e aí sim a necessidade deste try, catch, finally torna-se muito fiavel.

O seu funcionamento é bem simples, o try encarrega-se de “tentar” executar a acção, enquanto que o catch se ocupa de “captar” todos os possiveis erros que aconteçam ao executar a acção e o finally encarrega-se de executar uma acção no final de tudo, quer exista erro ou não. Este finally é opcional e quanto ao catch podemos usar quantos quisermos, para cada tipo de erro especifico ou erros em geral. Seguindo com um exemplo…

Vejam o código:
[coolcode]
var pops:int=systemManager.numChildren;
var x:int=1;

while(pops > x){
try {
PopUpManager.removePopUp((systemManager.getChildAt(x) as IFlexDisplayObject));
pops=systemManager.numChildren;
}
catch(e:Error) {
trace(“Error: “+e.message);
pops=systemManager.numChildren;
x++;
}
finally {
trace(“Child encontrado : “+systemManager.getChildAt(x).name);
}
}
[/coolcode] 

Como vos disse, o finally não é necessário, mas podemos coloca-lo como mostra em cima. Aproveitei para vos fornecer este código porque é muito util, no meu caso a minha aplicação apenas trabalha com popUpWindows, que juntamente com o “stage” principal são as unicas adicionadas como childs ao systemManager, logo a display list do system manager é composta por:

[0] -> Stage

[1]-> popUpXXX0

[2]-> popUpXXX1

Por isso eu ter indicado while(systemManager.numChildren > x) onde o x=1 , visto que se indicasse com o …systemManager.getChildAt(x)  onde o x fosse 0  ele não conseguiria tratar esse child (stage) como iFlexDisplayObject (ou seja, não é um popUp) logo o PopUpManager não o iria remover mas estranhamente também não disparava qualquer erro , logo o systemManager.numChildren é sempre superior a 0  que faria com que o while fosse executado eternamente resultando num crash  do flash.

Este código apenas funciona com popUps (IFlexDisplayObject) pelo que devem ter em especial atençao a utilização do mesmo que como indiquei em cima resulta num crash do flash no caso de tentarem remover o que não devem…se existir um erro ao remover algo que não devem, ele simplesmente assume que o child que existe não pode ser removido, incrementado então o x visto que se não o fizer o ciclo será executado eternamente.

Este try, catch, finally é muito util principalmente para lidar com os erros, prevendo assim eventuais falhas na aplicação. O try pode ainda suportar varios tipos de catch como disse en cima, por exemplo:

[coolcode]
var meuLoader:URLLoader;
try{
meuLoader= new URLLoader(new URLRequest(“meuFicheiro.txt”));
}
catch(erro:IOError) {
trace(“ERRO I/O”+erro.message);
}
catch(erro:SecurityError) {
trace(“ERRO DE SEGURANCA”+erro.message);
}
finally{
trace(‘Erros do loader tratados’);
}
[/coolcode]
 

Simples não?

Espero que seja util.

Cumprimentos.