Hur ActionScript 3.0-händelsehantering skiljer sig från tidigare versioner

Flash Player 9 och senare, Adobe AIR 1.0 och senare

Den mest utmärkande skillnaden mellan händelsehantering i ActionScript 3.0 och händelsehantering i tidigare versioner av ActionScript är att det i ActionScript 3.0 bara finns ett system för händelsehantering. I tidigare versioner av ActionScript finns det flera händelsehanteringssystem. Det här avsnittet börjar med en översikt över hur händelsehantering fungerade i tidigare versioner av ActionScript. Därefter beskrivs hur händelsehantering har ändrats för ActionScript 3.0.

Händelsehantering i tidigare versioner av ActionScript

ActionScript-versioner före ActionScript 3.0 erbjuder en rad olika sätt att hantera händelser på, bland annat följande:

  • on() -händelsehanterare som kan placeras direkt i Button- och MovieClip-instanser

  • onClipEvent() -hanterare som kan placeras direkt i MovieClip-instanser

  • Återkallningsfunktionsegenskaper som XML.onload och Camera.onActivity

  • Händelseavlyssnare som du registrerar med hjälp av metoden addListener()

  • Klassen UIEventDispatcher som delvis implementerade DOM-händelsemodellen.

Var och en av dessa mekanismer har sin egen uppsättning fördelar och begränsningar. Hanterarna on() och onClipEvent() är enkla att använda, men gör senare underhåll av projektet svårare eftersom kod som har placerats direkt i knappar och filmklipp kan vara svåra att hitta. Återkallningsfunktioner är också enkla att implementera, men begränsar dig så att du bara kan använda en återkallningsfunktion för en given händelse. Händelseavlyssnare är svårare att implementera eftersom de inte bara kräver att ett avlyssnarobjekt och en avlyssnarfunktion skapas, utan även kräver att avlyssnaren registreras med objektet som genererar händelsen. Det här extraarbetet gör dock att du kan skapa flera avlyssnarobjekt och registrera dem alla för samma händelse.

Utvecklingen av komponenter för ActionScript 2.0 gav upphov till ytterligare en händelsemodell. Den nya modellen, i form av klassen UIEventDispatcher, grundades på en deluppsättning av DOM-händelsespecifikationen. Utvecklare som är insatta i händelsehantering kommer därför inte att ha några större problem att gå över till den nya ActionScript 3.0-händelsemodellen.

Tyvärr sammanfaller syntaxen som används av de olika händelsemodellerna på olika sätt, och skiljer sig åt på andra sätt. I ActionScript 2.0 kan till exempel vissa egenskaper, som TextField.onChanged , användas antingen som en återkallningsfunktion eller som en händelseavlyssnare. Syntaxen för att registrera avlyssnarobjekt skiljer sig däremot åt beroende på om du använder någon av de sex klasser som stöder avlyssnare eller klassen UIEventDispatcher. För klasserna Key, Mouse, MovieClipLoader, Selection, Stage och TextField använder du metoden addListener() , men för komponenthändelsehantering använder du en metod som heter addEventListener() .

En annan svårighet som de olika händelsehanteringsmodellerna introducerade var att omfånget på händelsehanteringsfunktionen varierade avsevärt beroende på vilken mekanism som användes. Innebörden av nyckelordet this var med andra ord inte konsekvent mellan de olika händelsehanteringssystemen.

Händelsehantering i ActionScript 3.0

ActionScript 3.0 introducerar en enda händelsehanteringsmodell som ersätter de många olika händelsehanteringsmekanismerna som fanns i tidigare versioner av språket. Den nya händelsemodellen bygger på Document Object Model (DOM) Level 3-händelsespecifikationen. Även om SWF-filformatet inte följer DOM-standarden specifikt, finns det tillräckligt med likheter mellan visningslistan och DOM-strukturen för att göra det möjligt att implementera DOM-händelsemodellen. Ett objekt i visningslistan är detsamma som en nod i DOM-hierarkistrukturen, och termerna visningslisteobjekt och nod används båda för att beteckna samma sak.

Flash Player- och AIR-implementeringen av DOM-händelsemodellen innefattar begreppet standardbeteende. Ett standardbeteende är en åtgärd som Flash Player eller AIR utför som standard i samband med vissa händelser.

Standardbeteenden

Utvecklare har normalt ansvar för att skriva kod som svarar på händelser. I vissa fall är dock ett beteende så självklart kopplat till en händelse att Flash Player eller AIR automatiskt utför det beteendet, såvida inte utvecklaren lägger till kod som upphäver det. Eftersom Flash Player eller AIR uppvisar beteendet automatiskt kallas sådana beteenden standardbeteenden.

Om en användare till exempel anger text i ett TextField-objekt är det så självklart att texten förväntas visas i det TextField-objektet att detta beteende har byggts in i Flash Player och AIR. Om du inte vill att detta standardbeteende ska gälla, kan du avbryta det genom att använda det nya händelsehanteringssystemet. När en användare anger text i ett TextField-objekt, skapar Flash Player eller AIR en instans av klassen TextEvent som ska representera användarens indata. För att förhindra att Flash Player eller AIR visar texten i TextField-objektet måste du komma åt den specifika TextEvent-instansen och anropa den instansens preventDefault() -metod.

Vissa standardbeteenden går inte att förhindra. Flash Player och AIR genererar till exempel ett MouseEvent-objekt när en användare dubbelklickar på ett ord i ett TextField-objekt. Standardbeteendet, som inte går att förhindra, är att ordet under markören markeras.

Många typer av händelseobjekt saknar standardbeteenden. Flash Player skickar till exempel ett connect-händelseobjekt när en nätverksanslutning upprättas, men det finns inget standardbeteende kopplat till objektet. I API-dokumentationen för klassen Event och dess underklasser beskrivs alla typer av händelser och deras associerade standardbeteenden, och den innehåller även information om huruvida ett beteende går att förhindra eller inte.

Det är viktigt att veta att standardbeteenden bara är kopplade till händelseobjekt som skickas av Flash Player eller AIR och att de inte existerar för händelseobjekt som skickas med programkod via ActionScript. Du kan till exempel använda metoderna för klassen EventDispatcher för att skicka ett händelseobjekt av typen textInput , men det kommer inte att finnas något standardbeteende kopplat till det händelseobjektet. Flash Player kommer med andra ord inte att visa ett tecken i ett TextField-objekt som ett resultat av en textInput -händelse som du skickade med programkod.

Nyheter för händelseavlyssnare i ActionScript 3.0

För utvecklare med erfarenhet av att använda metoden addListener() i ActionScript 2.0 kan det vara till hjälp att nämna skillnaderna mellan händelseavlyssnarmodellen i ActionScript 2.0 och händelsemodellen i ActionScript 3.0. I listan nedan beskrivs några av de viktigaste skillnaderna mellan de båda händelsemodellerna:

  • För att lägga till händelseavlyssnare i ActionScript 2.0 använder du addListener() i vissa fall och addEventListener() i andra. I ActionScript 3.0 använder du däremot addEventListener() i alla situationer.

  • Det finns inget händelseflöde i ActionScript 2.0, vilket innebär att metoden addListener() bara kan anropas i objektet som sänder händelsen. I ActionScript 3.0 kan däremot metoden addEventListener() anropas i valfritt objekt som ingår i händelseflödet.

  • I ActionScript 2.0 kan händelseavlyssnare vara funktioner, metoder eller objekt. I ActionScript 3.0 kan bara funktioner och metoder vara händelseavlyssnare.