Ressources Mediabox

Méthodes et propriétés statiques - lienforum

olivier tarasse — Thu, 29 Jul 2010 19:35:11 +0200

Introduction
Classe de base (#1)
Classe de base (#2)
Héritage et surcharge (#1)
Héritage et surcharge (#2)
Diffuser des événements
Classe liée
Classe de document
Classe externe : une visionneuse (#1)
Classe externe : une visionneuse (#2)
Classe externe : méthodes statiques

Méthodes et propriétés statiques

Ça y est la balade touche à sa fin. On a vu le plus gros du primordial. Ne reste plus à traiter que le cas du mot clé attribut static, attaquons donc sans plus de préambule.

C'est un mot clé bien utile : il permet de spécifier qu'une méthode (variable ou constante) appartient à la classe, et non pas aux occurrences de la classe. C'est la doc qui le dit.
Présenté autrement : c'est utile quand on souhaite se fabriquer ce que j'ai appelé une classe outil en introduction. Une classe qu'on souhaite utiliser sans en créer d'instance, justement. J'avais pris pour exemple le volume d'un tonneau… Vous vous souvenez ?

Méthode statique

Une méthode statique, donc, est appelée directement depuis la classe sans nécessité d'en créer une instance.
On peut prendre pour exemple, une classe native fréquemment utilisée que vous connaissez sûrement : la classe Math. Elle met à notre disposition une quantité de méthodes, toutes statiques (cos, floor, max…). C'est clairement lisible dans leur signature. Prenons la méthode cos, :

public static function cos(angleRadians:Number):Number

Je vous propose, à titre d'exemple, une classe générique de traitement des dates que vous pourrez fort bien ranger dans le répertoire Mezoutils (du moins l'équivalent chez vous)

La classe Date native nous donne déjà beaucoup d'outils bien utiles, mais dès qu'on sort des chemins battus on se fait suer pour calculer une différence entre deux dates ou plus bêtement le numéro du jour (de l'année : 32 pour le 1er février). Il suffit d'en avoir besoin une fois pour se dire que “pff… Il serait bon de stocker les quelques lignes quelque part…”
C'est le cadre idéal à la création d'une classe.

Comme d'habitude on commence par rêver, par imaginer comment on aimerait l'utiliser, cette classe.
On l'appèlerait GestionDates.
Comme on n'a pas besoin d'en manipuler des instances, l'idéal serait d'appeler ses méthodes directement. Imaginons une méthode numJour qui renverrait le numéro du jour de l'année :

// le .fla
 
import GestionDates
var laDate:Date=new Date("2010/2/1");
trace (GestionDates.numJour(laDate))

Normalement (du moins avec ce qu'on sait) invoquer une méthode c'est invoquer la méthode d'un objet de la classe (une instance de la classe). Si on écrit la classe GestionDates comme on sait le faire avec une méthode publique numJour…

package {
 
	public class GestionDates {
 
		// numéro du jour depuis le premier janvier de la même année
		public function numJour(pD:Date):int {
			// retourne n'importe quoi le temps de tester
			return 88;
		}
	}
}

… et qu'on essaie de l'appeler comme dans nos rêves, on obtient une erreur à la compilation :

1061: Appel à la méthode numJour peut-être non définie, via la référence de type static Class.

Si je traduis ce que râle le compilateur ça donne : “Hey Machin ! Tu fais appel à une méthode statique numJour et je ne la trouve pas…”

Quoi statique ?! On n'a rien précisé…
Justement… Il se trouve qu'on peut invoquer une méthode de classe depuis la classe elle même, mais ça implique qu'elle soit statique. C'est ce qui a trompé le compilateur : il voit un appel direct, il se dit “tiens, une méthode statique”, il ne la trouve pas, il récrimine…

Ajoutez static devant le nom de fonction, ayé le tour est joué

                public static function numJour(pD:Date):int {
			// retourne n'importe quoi le temps de tester
			return 88;
		}

A noter :
Pas de this dans une fonction statique puisque il n'y a pas d'instance…

Constante statique

Travailler des dates implique de travailler avec des millisecondes, ce qui est loin d'être pratique… Le nombre de millisecondes contenues en un jour, autant se le calculer une bonne fois pour toutes et en faire une constante globale privée et statique elle aussi puisque concernant la classe et non ses instances. On la définit donc en haut du bloc classe comme suit :

		private static const msJour:Number=1000*60*60*24;

Il ne reste plus qu'à écrire les deux lignes qui vont bien dans la fonction :

		public static function numJour(pD:Date):int {
			var premierJour:Date=new Date(pD.fullYear,0,1);
			return (pD.getTime() - premierJour.getTime() ) /msJour+1;
		}

Et du coup à moindre frais on peut ajouter à cette classe une autre méthode dateDiff qui donne le nombre de jours entre deux dates :

		public static function dateDiff(pD1:Date,pD2:Date):int {
			return (pD1.getTime()-pD2.getTime())/msJour;
		}

C'était donc ça ! S'exclame Ronchon, en faisant référence à ce qu'on a mis en place quand on a vu comment diffuser un événement.
Hé oui, souvenez vous : avec nos boites modales on avait diffusé un événement BtClick, et pour respecter les conventions d'écriture, on avait sorti une constante statique BT_CLICK

public static const BT_CLICK:String="BtClick";

Ce qui nous permettait d'y accéder directement depuis la classe BoiteAlerte - et non depuis une de ses instances :

bteDemo.addEventListener(BoiteAlerte.BT_CLICK,compte);

Là aussi, force est de constater qu'on utilise des constantes statiques depuis tout le temps avec les classes natives… Je pense, par exemple, à la classe MouseEvent, une des premières qu'on utilise et qui expose MOUSE_DOWN, CLICK et autres ROLL_OVER.

Variable statique

On peut aussi déclarer une variable (ou une fonction) comme étant statique, au sein d'une classe qui instancie des objets.
Ne croyez pas que le mot clé static soit réservé aux classes qui n'instancient rien. Il signifie seulement que la variable en question qualifie la classe et non chacune de ses instances, ou que la méthode sera appelée depuis la classe et non depuis une de ses instances.

Une petite illustration plutôt qu'un long discours :

Soit une classe destinée à être associée à un symbole (donc instances) :

package {
	import flash.display.MovieClip;
 
	public class DemoStaticProp extends MovieClip {
                // une statique :
		public static var nbOccurences:int=0;
 
		public function DemoStaticProp() {
                        // statique incrémentée
			nbOccurences++;
			trace("constructeur "+ this+ " nb occurences "+ nbOccurences);
 
		}
	}
}

Du côté du .fla on associe un ou plusieurs symboles à cette classe (via le champ Classe de base) et on dispose des instances sur la scène :

Et on écrit une unique ligne en action d'image 1 :

trace("ds le fla je compte les instances : "+DemoStaticProp.nbOccurences);

constructeur [object Mv_Girafe] nb occurences 1
constructeur [object Mv_Elephant] nb occurences 2
constructeur [object Mv_Girafe] nb occurences 3
constructeur [object Mv_Elephant] nb occurences 4
constructeur [object Mv_Elephant] nb occurences 5
constructeur [object Mv_Girafe] nb occurences 6
ds le fla je compte les instances : 6

Pour finir la démonstration, occupons nous de faire en sorte que la variable de classe nbOccurences soit mise à jour quand on supprime une instance :

package {
	import flash.display.MovieClip;
	import flash.events.Event
 
	public class DemoStaticProp extends MovieClip {
		public static var nbOccurences:int=0;
 
		public function DemoStaticProp() {
			nbOccurences++;
			trace("constructeur "+ this+ " nb occurences "+ nbOccurences);
                        // Ecouter la suppression
			addEventListener(Event.REMOVED_FROM_STAGE, supprime);
		}
                // Quand supprimé nbOccurences décrémenté
		function supprime(e:Event) {
			nbOccurences--;
		}
	}
}

Dans le fla :

trace("ds le fla je compte les instances : "+DemoStaticProp.nbOccurences);
 
// j'écoute le clic sur enfants de la scène : argument true)
addEventListener(MouseEvent.CLICK, sup,true);
 
function sup(me:MouseEvent) {
	removeChild(MovieClip(me.target));
	trace("Il reste : "+DemoStaticProp.nbOccurences);
}

Conclusion

Voilà, non pas que tout soit dit…
Loin de là, mais j'espère que maintenant vous avez les idées claires et disposez du vocabulaire nécessaire à lire la doc ou des ouvrages traitant de POO AS3 sans butter sur tous les mots

• L'incontournable de Thibault Imbert

• Un tuto classique sur les classes et la POO AS3 par Tannoy

• Sans oublier la doc, bien sûr

Vous pourrez mettre en œuvre vos toutes fraiches connaissances via le tuto de Gnicos Déplacer un objet d'après les coordonnées de la souris.

Je vous remercie de m'avoir accompagnée jusque là, j'y ai gagné beaucoup à tout décortiquer de la sorte, je vous souhaite bonne route pour la suite et… à bientôt peut-être, quelque part dans les ressources, sait-on jamais…

Créer des images originales grâce aux coordonnées polaires

Adrien — Wed, 28 Jul 2010 19:35:28 +0200

EN CHANTIER !
Cette page n'est pas terminée et est en cours d'écriture.

Créer des images originales grâce aux coordonnées polaires

Les coordonnées polaires peuvent donner des effets surprenants ! A partir d'une simple déformation, qu'on répète, qu'on répète … Nous verrons dans ce tutoriel, le principe de base, et les diverse amélioration et variations que l'on peut apporter.

Prérequis

Posséder des connaissances de bases sur Photoshop CS4
Un bon sens de l'esthétique !

Le principe

L'avantage de cette technique, c'est qu'elle fonctionne avec n'importe quelle forme de base. Vous pouvez faire un trait, un rond, ou du gribouillage, le rendu est pratiquement pareil. Il n'y a donc pas besoin de s'appliquer.

Donc, ouvrez un nouveau document (fond blanc, 454×340). Pour commencer, on va utiliser une seule couleur, du noir. Et maintenant, gribouillez

Attention a remplir suffisamment la zone de travail en élément, pour espérer obtenir le rendu complet, et pas seulement une partie

Voici mon œuvre

Maintenant, il faut appliquer le filtre de déformation rectangulaire en polaire. Ctrl + F pour le répéter 4-5 fois.

Et voila !!

Commencer à contrôler le rendu

C'est bien beau tout ça, mais c'est toujours pareil … Et bien non (Haha !)

La quantité "d'encre"

(Le noir utilisé me fait penser à de l'encre, d'où le nom de quantité d'encre !).

Nous avons déjà vu précédemment le principe, ainsi qu'il faut assez remplir la zone de travail pour avoir un bon rendu. Vous pouvez deviner que si elle n'est pas assez remplit, le rendu aura la même forme, mais sera beaucoup moins remplit. Cela peut donc être exploité !

A gauche, le résultat avec peu de “gribouillage” (j'ai simplement fait un trait), à droite, plus de “gribouillage”.

Les couleurs

Rien de plus simple, il suffit de gribouiller d'une autre couleur que le noir, et le tour est joué !

Et pour le blanc ?

Il y a plusieurs façon. Au début j'ai demandé de gribouiller, mais moi j'ai pris garde sur mes modèle à ne pas toucher les bords de la zone de travail lors du “gribouillage” (Oui bon, pour celui avec beaucoup “d'encre” ce n'est pas très évident).

Vous remarquerez que la forme obtenu noir est uniquement au milieu du sujet, on ne retrouve pas de trace noir autour (Sauf mon modèle “Beaucoup d'encre”). En effet, plus on s'approche du bord, plus il y aura une teinte de la couleur du “gribouillage” autour du rendu. Et si on touche complètement TOUT le bord, ce ne sera pas une teinte légère de la couleur choisie, mais une teinte très très forte (Si bien qu'on ne peut plus distinguer la forme qu'on obtient normalement, on trouve un carré de notre couleur).

Voyez vous ? Ici j'ai uniquement mis du noir sur les bords. Le rendu ?

*Retour au sujet principal* Ça alors ! Du blanc !

Plus simple pour obtenir notre forme en blanc ?
Remplir la zone de travail en noir, et gribouiller en blanc, tout simplement

Et si on commençait à mettre plusieurs couleurs ?

En cours de rédaction …

Conclusion

En cours de rédaction …

Les sources

Vous pouvez proposer au téléchargement tout document qui serait bienvenue pour le lecteur, par exemple le fichier .psd photoshop, le .fla pour flash, etc

En savoir plus

En cours de rédaction …

Diffuser des événements

Nataly — Mon, 26 Jul 2010 17:44:06 +0200

Introduction
Classe de base (#1)
Classe de base (#2)
Héritage et surcharge (#1)
Héritage et surcharge (#2)
Diffuser des événements
Classe liée
Classe de document
Classe externe : une visionneuse (#1)
Classe externe : une visionneuse (#2)
Classe externe : méthodes statiques

Diffuser des événements

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.

Hé oui, ne serait-ce que pour faire cette petite nouillerie, il nous faut un événement (diffusé par la classe BoiteAlerte au clic sur son unique bouton). Un événement qu'on écouterait comme tous les événements du monde as3 avec addEventListener :

var bteDemo:Mv_BoiteAlerte=new Mv_BoiteAlerte();
// [...]
 
// associer un écouteur sur l'événement maison
bteDemo.addEventListener(BoiteAlerte.BT_CLICK,compte);
 
// la fonction de rappel
var compt:int=0;
function compte(e:Event) {
	compt++;
	txtSortie.text="Boite affichée "+compt+" fois";

Si vous êtes encore là et que vous n'avez pas jeté l'éponge (le sac à dos et les croquenots), dites vous que la côte la plus raide est franchie. Diffuser un événement tient de la formalité.

Si je reprends la métaphore du début, il s'agit pour nous de faire en sorte que la boite “crie” un truc quand on clique sur le bouton. Elle criera “on a cliqué sur mon bouton OK”, nous n'aurons donc qu'à écouter cet événement, pour y “brancher” la fonction de notre choix, comme illustré au dessus.

Crier un truc, plus académiquement dit c'est diffuser un événement, outre-atlantique diffuser c'est dispatch.
Faire diffuser un événement par un objet, c'est donc utiliser cette syntaxe :

l_Objet.dispatchEvent( ... );

Les points de suspension valant un événement

Créer un événement, ça se fait à l'aide du mot clé new, comme toujours (puisque c'est un objet, puisque tout est Objet - POO on a dit).

new Event ( "nom_De_L_Evénement" )

Dans le cas qui nous occupe il faut tout bonnement diffuser un événement maison au clic sur le bouton, donc dans la fonction btOKQdClick.

		private function btOKQdClick(me:MouseEvent):void {
			trace("ferme ");
			ferme();
			dispatchEvent( new Event ("BtClick" ));
		}

On choisit le nom qu'on veut, mais bien sûr, plus il sera parlant mieux ce sera.
On pourrait dès maintenant écouter cet événement :

bteDemo.addEventListener("BtClick",compte);

Respecter les conventions d'écriture

… mais puisque maintenant on joue dans la cours des grands (Si, si… Allez ! Un peu d'autosatisfaction bien mesurée de peut pas nuire ), on va faire les choses vraiment bien et respecter les standards ActionScript 3 qui veulent que tous les événements soient stockés dans des propriétés constantes de la classe liée à l'événement.

En français courant : utiliser une variable globale publique constante (et statique, acceptez le comme tel, j'expliquerai ce qu'est ce mot static en fin de parcours)

	public class BoiteAlerte extends BoiteModale {
		public var prompt:String="";
                // ici la constante :
		public static const BT_CLICK:String="BtClick";

Et ben voilà, c'est tout. C'est fini, la classe est parfaitement fonctionnelle

Bien entendu puisqu'on utilise la propriété BT_CLICK de la classe (dans l'écouteur), il faut l'importer :

import Interface.BoitesModales.BoiteAlerte;

Enregistrement de l'écouteur :

bteDemo.addEventListener(BoiteAlerte.BT_CLICK,compte);

Classe EventDispatcher

C'est bien pratique de pouvoir aussi facilement diffuser des événements
Le mérite en revient à la classe EventDispatcher (diffuseur d'événements chez Molière) dont la classe MovieClip hérite.
C'est le résultat d'une très longue lignée d'héritage. Allons voir ce qu'en raconte la doc :

Les flèches se lisent : hérite de…
MovieClip hérite de Sprite qui hérite de DisplayObjectContainer qui hérite de InteractiveObject qui hérite de DisplayObject qui hérite de EventDispatcher qui hérite de Object.

D'ailleurs si on clique sur EventDispatcher, la doc nous dresse la liste de toutes les classes qui en héritent directement, comme vous le voyez ça fait du monde, on va pouvoir en abuser de cette technique
Qui râle qu'on n'y trouve pas MovieClip ?
Directement, j'ai dit.
MovieClip est l'arrière-arrière-petite fille de DisplayObject…

Si vous prenez l'habitude d'aller régulièrement jeter un œil aux en têtes de la doc, vous vous y retrouverez très vite…

Mise en œuvre : la boite Oui/Non

Pour vous faire la main, je vous laisse écrire la classe BoiteOuiNon. C'est une classe de base qui sera associée à des symboles contenant deux boutons (au lieu d'un, la belle affaire ) et un champ texte.
Chacun des boutons fermera la boite et la boite diffusera deux événements BTOUI_CLICK et BTNON_CLICK

Comme sur le swf d'introduction

Et puis même, pour ceux qui ont envie de trainasser encore un peu en terrain apprivoisé et de jouer avec leurs nouveaux copains du pays de Poo, il y a l'idée de se faire une boite de saisie…
(Mais ça, c'est vraiment pour le plaisir de musarder encore un peu parce qu'il est rarissime d'avoir besoin d'une boite de saisie modale

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.

Ensuite nous reprendrons la route par le versant classes liées, où on ne rencontrera rien de bien neuf, si ce n'est… une surprise…
Non, je ne dis pas ce que c'est, vous verrez bien. Ça n'a pas à voire avec les classes ce sera le bonus hors pistes.

Les classes
Boites alerte et oui/non mise en œuvre
Boite saisie mise en œuvre

Les classes liées -->

Visionneuse (#2) Finitions

Nataly — Mon, 26 Jul 2010 17:33:39 +0200

Introduction
Classe de base (#1)
Classe de base (#2)
Héritage et surcharge (#1)
Héritage et surcharge (#2)
Diffuser des événements
Classe liée
Classe de document
Classe externe : une visionneuse (#1)
Classe externe : une visionneuse (#2)
Classe externe : méthodes statiques

Visionneuse (#2) Finitions

le sens de défilement

Changer le sens de défilement, ce n'est pas sorcier : il suffit de décrémenter idxSup (idxSup–). Il y a différente façon de s'y prendre, toutes passeront par un test sur une variable précisant le sens… Les moins aguerris auront peut être l'idée de valoriser une variable sens avec une chaine (genre avant ou arrière) et d'écrire dans un if soit idxSup++, soit idxSup–. Pas mal, mais peut mieux faire. On va décider d'une propriété qui vaudra 1 ou -1, ainsi la seule ligne idxSup+=laPropSens; permettra-t-elle d'incrémenter ou de décrémenter selon la valeur de la proriété.
Il faut aussi faire attention à ce qui se passe quand tous les visuels ont défilé. Il faut que idxSup vaille 1 quand on avance et le dernier numéro d'index quand on recule. Ça peut s'écrire comme ça :

			idxSup+=_sens;
			if (_sens==1) {
				idxSup=idxSup>NumPhotoMax?1:idxSup;
			} else {
				idxSup=idxSup<1?NumPhotoMax:idxSup;
			}
			idxInf=idxTmp;

Si les opérateurs ternaires ne vous plaisent pas, ne vous privez pas de les remplacer par la structure de contrôle if…else

Tant qu'à faire, faisons en sorte de pouvoir préciser le sens à l'initialisation.
Un paramètre supplémentaire et facultatif dans le constructeur fera l'affaire. Je vous laisse écrire un couple d'accesseur pour la propriété sens.

                // [...]
 
		private var _sens:int=1;
                // Le constructeur, un sens par défaut
		public function VisioPazapa(pTabVisuels:Array, pMasque:MovieClip,pSens:int=1):void {
 
			NumPhotoMax=pTabVisuels.length-1;
			tabVisuels=pTabVisuels;
			// 
			_sens=pSens;
                        // index image sup selon sens 
			idxSup= pSens==1?1:NumPhotoMax;
 
                // [...]
 
                // Les accesseurs
 
		public function set sens(pSens:int):void {
			_sens=pSens;
		}
		public function get sens():int {
			return _sens;
		}
 
                // [...]

C'est parfait aussi longtemps qu'on le teste à l'initialisation, mais si nous vient l'idée d'installer sur le fla deux boutons pour changer le sens en cours de route :

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.

… il y a un décalage, la commande n'est pas prise en compte tout de suite.
Je m'explique : l'enchainement des images sur la démo publiée c'est cabane, château, chemin. Si on modifie la propriété sens (à -1) pendant que la transition s'effectue de château à chemin, on aimerait voir château dès la transition suivante, or il faut attendre un tour de plus. C'est cabane qui s'affiche, ensuite seulement le défilement se fera à reculons.

En effet, c'est bien gentil de modifier _sens via l'accesseur set, mais les valeurs de idxSup et idxInf ne seront modifiées qu'à la sortie de la fonction chargeVisuels, d'où le décalage. Il faut donc intervenir dans le setter afin de modifier certes la variable sens, mais aussi idxSup et idxInf.

		public function set sens(pSens:int):void {
			var supTemp:int=idxInf+pSens;
			_sens=pSens;
 
			if (_sens==1) {
				idxSup=supTemp>NumPhotoMax?1:supTemp;
			} else {
				idxSup=supTemp<1?NumPhotoMax:supTemp;
			}
		}

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.

Temps de pause

Plus rigolo : le temps d'exposition du visuel avant enchainement, ce que j'appelle temps de pause.
Tel qu'écrit, la transition se fait dès que la lecture du masque revient image 1. Si on veut un temps de pause il va s'agir, arrivé à la dernière image, d'arrêter la lecture et d'attendre le temps précisé avant de la relancer (la lecture).
Arrêter c'est stop() (wo ! la découverte )
Attendre avant d'invoquer une fonction il nous faut un objet Timer (petit rappel ici)
Quant à la fonction invoquée le délai passé, on l'a déjà c'est marche.

L'objet Timer va être déclaré en variable globale et privée

	import flash.utils.Timer;
	import flash.events.TimerEvent;

		private var _tpsPause:int=2000;
		private var tmPause:Timer=new Timer(_tpsPause,1);

On a anticipé bien sûr une variable globale privée (_tpsPause) pour le temps de pause, toute prête à être modifiée via accesseurs tpsPause.
Dans le constructeur on va ajouter un écouteur à tmPause et lui souscrire la fonction marche.

tmPause.addEventListener(TimerEvent.TIMER,marche);

Voilà, il n'y aura plus qu'à appliquer la méthode start à tmPause pour remettre la visionneuse en route après un délai de deux secondes. On va le faire dans une fonction attendre :

		private function attendre() {
			masque.stop();
			trace("j'attends");
			tmPause.reset();
			tmPause.start();
		}

Cette toute bête fonction attendre, il ne nous reste plus qu'à l'appeler sur la dernière image du masque. Dit autrement : il faut ajouter du script sur la dernière image de masque…
Et hop ! On re-dégaine la fameuse addFrameScript.

		public function VisioPazapa(pTabVisuels:Array, pMasque:MovieClip,pSens:int=1):void {
			trace("constructeur visio : " + pTabVisuels + "\nmasque : "+pMasque);
			tmPause.addEventListener(TimerEvent.TIMER,marche);
 
			NumPhotoMax=pTabVisuels.length-1;
			tabVisuels=pTabVisuels;
			_sens=pSens;
			idxSup=pSens==1?1:NumPhotoMax;
			masque=pMasque;
			masque.filters=[new BlurFilter(10,10,BitmapFilterQuality.HIGH)];
			masque.gotoAndStop(2);
			// ajouter du code première et dernière image de masque
			masque.addFrameScript(0,chargeVisuels);
			masque.addFrameScript(masque.totalFrames-1,attendre);
			addChild(masque);
			masque.gotoAndStop(1);
		}

C'est un peu crétin de forcer le temps de pause sur 2 secondes, je vous laisse donc créer une propriété tpsPause d'un couple d'accesseurs :

 
		private var _tpsPause:int=2000;
 
                //[...]
 
		public function set tpsPause(pTpsPause:int):void {
			_tpsPause=pTpsPause;
			tmPause.delay=_tpsPause;
		}
		public function get tpsPause():int {
			return _tpsPause;
		}

Depuis le .fla on peut tester nos dernières sophistications.

// .fla
 
function nouvelleVisionneuse() {
	// nouvelle instance initialisée avec le tableau et le masque
	visio=new VisioPazapa(tabPhotos,leMasque,-1);
	visio.addEventListener(MouseEvent.CLICK,marcheArret);
	// fixer le temps de pause
	visio.tpsPause=5000;
 
	addChild(visio);
}//

En testant en l'état on constate que la méthode arrêt semble ne pas toujours fonctionner : si on arrête la lecture en cliquant pendant le temps de pause, et bien… la lecture s'enchaine malgré tout.
Rien de plus normal : sur la dernière image tmPause est lancé, si on veut l'empêcher de faire son boulot et d'appeler la méthode marche après le délai, il faut l'arrêter :

		public function arret() {
			trace("arret");
			tmPause.stop();
			masque.stop();
		}

AddFrameScript deux trois choses à savoir

On l'a dit et répété, la méthode addFrameScript n'est pas documentée, ce qui lui vaut mauvaise presse : est-ce bien sérieux ? Ne risque-t-elle pas de disparaître un jour sans préavis ?
Je n'en sais rien : j'ai bien des qualités (en tout premier lieu la modestie) mais je ne suis pas médium… En revanche je suis butée. J'ai donc pris le temps d'observer son comportement, et voici les conclusions surprenantes auxquelles je suis arrivée. Allez y jeter un coup d'œil avant de l'utiliser à nouveau

Diffuser un événement "image suivante"

Si on veut pouvoir l'utiliser avec suffisamment de souplesse cette visionneuse, il serait bon qu'elle diffuse pour le moins un événement au chargement de chaque nouvelle image, ne serait-ce que pour pouvoir adjoindre des commentaires aux photos, par exemple…

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.

Du côté du .fla il faut :
• Un champ texte dynamique sur le scenario, et un tableau pour stocker les chaines de commentaires.

var tabLegendes:Array=new Array("Cabane","Chateau","Chemin");

• Ecouter l'événement qu'on se propose d'ajouter à la classe pour écrire dans le champ texte.

function nouvelleVisionneuse() {
	var leMasque:Mv_Masque0=new Mv_Masque0();
	visio=new VisioPazapa(tabPhotos,leMasque);
	visio.addEventListener(MouseEvent.CLICK,marcheArret);
        // --- > Ecouter l(e futur) événement SUIVANT
	visio.addEventListener(VisioPazapa.SUIVANT,imgSuivante);
	visio.tpsPause=2000;
	// ajouter à la liste d'afichage
	addChildAt(visio,0);
}
// la fonction de rappel
function imgSuivante(e:Event) {
	txtLegende.text=tabLegendes[visio.visuelCourant-1];
}

Du côté de la classe

Ce qui implique pour vous de modifier la classe afin qu'elle diffuse l'événement idoine et qu'elle expose une propriété visuelCourant en lecture seule.
J'ai bien dit “ce qui implique pour vous“… Puisque tout ça vous savez le faire ! J'avais prévenu, c'est une excuse à réemployer ce qui a été vu jusqu'ici, une excuse pour jouer avec tout ce petit monde fraichement rencontré .
Diffuser un événement on l'a fait là.
Une propriété en lecture seule c'est un accesseur get sans le set, voilà tout
Et dans l'élan vous pourrez, si le cœur vous en dit, ajouter un événement diffusé lorsque la visionneuse atteint le dernier visuel. Ça permettra, le cas échéant, d'arrêter le défilement en fin de lecture - depuis le .fla.

Allez je vous laisse, je vais chercher les cafés, tout le monde en veut ?

zip : les sources complètes

Ecouter l'affichage

Oui, il y avait un piège… Rhooo… A peine, une petite chose à réfléchir pour que l'événement SUIVANT soit diffusé dès le chargement.
Si vous l'avez diffusé à l'entrée de chargeVisuels et rien modifié d'autre, forcément il semble n'être diffusé qu'au deuxième passage dans la fonction. Regardons le code du fla :

        visio=new VisioPazapa(tabPhotos,leMasque);
	[...]
	visio.addEventListener(VisioPazapa.SUIVANT,imgSuivante);
	[...]
	addChildAt(visio,0);

Première ligne reproduite : on crée une instance, donc le constructeur est sollicité et la fonction chargeVisuels invoquée. Elle diffuse bien l'événement, mais on ne l'écoute pas encore…

Pour régler le problème il suffit de passer dans chargeVisuels après avoir souscrit l'écouteur, au addChild par exemple Et c'est là qu'on se souvient de addedToStage diffusé par les DisplayObject quand ils sont ajoutés à la liste d'affichage.

		public function VisioPazapa(pTabVisuels:Array, pMasque:MovieClip,pSens:int=1):void {
			[...]
			addEventListener(Event.ADDED_TO_STAGE,chargePhotos);
		}
 
		private function chargePhotos(e:Event=null) {
			trace("chargePhotos ");
			dispatchEvent( new Event ("suivant" ));
			[...]

Et par la même occasion plus utile d'appeler chargeVisuels. Que vous ayez utilisé chargeVisuels() ou gotoAndStop(1), vous pouvez supprimer cette ligne.

Mais… Du coup…

Ne vous y trompez pas: Ronchon ne ronchonne pas il se demande, nuance…

L'œil rivé aux deux exemples de classes document du chapitre précédent, il se dit que somme toute… c'est la même structure qu'une classe “tout court”.
Bien vu La seule différence entre une classe de document et une classe que j'ai dite classique en intro (souvenez vous c'était il y a longtemps…) c'est le contexte dans laquelle on va l'utiliser. Pour pouvoir l'associer à un clip ou à un fla (ce qui revient au même, maintenant vous n'êtes plus dupes), il convient seulement qu'elle étende MovieClip ou Sprite.
Pour peu qu'elle ne fasse pas référence à des objets (clips, champ texte…) présupposés sur le scénario, rien n'empêche d'utiliser une classe originellement conçue en tant que classe de document, pour instancier un objet.
On ne l'associe à rien, on invoque son constructeur à l'aide de l'opérateur new. Testez donc avec la classe issue de la doc : ColorTransformExample.as

var ct:ColorTransformExample=new ColorTransformExample()
addChild(ct)
var ct2:ColorTransformExample=new ColorTransformExample()
ct2.x=50;
addChild(ct2)

Vous obtenez deux instances de ColorTransformExample, chacune accepte le clic et se modifie de la couleur… Mais seulement elle…
Quand la classe était associée à MainTimeline, this c'était tout le scénario. Maintenant this c'est l'instance.

page suivante -->

Classe externe : une visionneuse (#1)

Nataly — Mon, 26 Jul 2010 17:32:12 +0200

Introduction
Classe de base (#1)
Classe de base (#2)
Héritage et surcharge (#1)
Héritage et surcharge (#2)
Diffuser des événements
Classe liée
Classe de document
Classe externe : une visionneuse (#1)
Classe externe : une visionneuse (#2)
Classe externe : méthodes statiques

Classe externe : une visionneuse (#1)

Nous voici bientôt arrivés au terme de la randonnée au pays de Poo, et ce nouveau chapitre va être une excellente excuse à mettre en œuvre tout ce qui a été vu jusqu'alors.
L'idée c'est de construire une classe visionneuse ou diaporama, ce qui revient au même…
Justement peut-être nos rangs sont ils grossis de quelques nouveaux arrivés via un moteur de recherche. Bienvenue à vous, sachez seulement que je considère comme acquis (ou en voie d'acquisition, on s'énerve pas) les points précédemment développés.

Je ne développerai pas :
• Ce qu'est une classe, comment ça se construit et les syntaxes dédiées
• Comment définir des méthodes, un constructeur ou des accesseurs
Je vous invite à vous reporter aux pages précédentes pour ces différents points.

Il vous faut aussi savoir appliquer dynamiquement un masque à un clip, et lui appliquer un flou.
On utilisera les classes loader et loaderInfo pour charger les images, mais ça n'a pas à voire directement avec la visionneuse, vous pouvez vous contenter d'admettre les quelques lignes concernées si d'aventure vous n'en êtes pas familiers.

intro

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.

Ça, c'est ce qu'on imagine obtenir à terme : des visuels qui s'enchainent avec une transition animée via un masque selon le principe illustré là. Vous le constatez, les images sont affichées en boucle, mais la première ne l'est qu'une fois.

Les boutons qui changent le sens de défilement ne font pas partie de la classe mais du fichier de mise en œuvre qui permet d'utiliser l'objet Visionneuse, même chose pour la légende.

La classe ne fait rien d'autre, donc, qu'afficher des visuels dans un clip vide et leur appliquer un masque. On ne va pas créer un symbole de bibliothèque vide juste pour lui associer une classe… On pourrait, mais 'faut rien exagérer non plus, il suffit que la classe s'en charge. Nous pouvons donc rêver d'une classe qu'on utiliserait comme suit :

// .fla
 
visio=new Visionneuse();
visio.addEventListener(MouseEvent.CLICK,marcheArret);
addChild(visio);
[...]

Elle mettrait à notre disposition une méthode marche, une méthode arrêt (ainsi que diverses petites choses qu'on inventera en cours de route), et n'aurait besoin pour fonctionner que d'un clip (animation de transition) et d'une série de visuels qu'on lui passerait sous forme d'un tableau. Du coup on l'initialiserait à la construction comme suit :

var visio:Visionneuse=new Visionneuse(tabPhotos,leMasque);

Ce qui est sympa avec le code, c'est que du rêve à la réalité il n'y a qu'un clavier, dont je vous propose de vous saisir sans plus attendre. C'est parti pour la visionneuse !

Côté .fla

Il nous faudra un fichier .fla de mise en œuvre et un fichier .as pour la classe, les deux étant considérés comme enregistrés dans le même répertoire.
Créons le fla pour commencer.

Charger les images

On sera amenés à utiliser la classe Visionneuse soit avec des visuels sous forme de symboles de la bibliothèque, soit sous forme de fichiers externes. Alors pour le plaisir de frimer qu'on sait tout faire, je vous propose de faire un mixte : charger une première image qui sera un symbole de bibli (la page de garde), les autres seront des images externes.

Mon point de vue étant qu'il vaut mieux écrire cinq fois dix lignes en les testant au fur et à mesure, qu'écrire une fois cinquante lignes qui plantent à l'exé (et qu'on sait même pas où, et qu'on se retrouve à poster deux écrans de code dans le forum sur le mode “au secours ça marche pô chépa pourquoi…” ) on va procéder par étapes en vérifiant régulièrement que “jusque là, ça va…”

Avant même d'attaquer la classe, occupons nous donc de fabriquer un tableau qui contiendra les visuels : un symbole de bibliothèque et des photos externes.

Je vous laisse fabriquer le clip pour le premier visuel, pensez à cocher la case exporter pour actionScript (pour en créer une instance dynamiquement), de mon côté je le nomme Mv_Photo0.

Charger les fichiers et fabriquer le tableau
On considère ici des images dans le même répertoire que les deux fichiers .fla et .as, nommées P1.jpg, P2.jpg, P3.jpg…

// .fla
 
var ldrFichier:Loader;
var ldrInfo:LoaderInfo;
 
var tabPhotos:Array=new Array();
var nbPhotos:int=3;
 
var visio:VisioPazapa;
 
var visuelDep:Mv_Photo0= new Mv_Photo0();
tabPhotos.push(visuelDep);
 
charge("P1.jpg");
 
function charge(pNom:String):void {
	ldrFichier= new Loader();
	ldrInfo=ldrFichier.contentLoaderInfo;
	ldrInfo.addEventListener(Event.COMPLETE, Fini);
	ldrFichier.load(new URLRequest(pNom));
}
 
function Fini(e:Event) {
        // remplir le tableau et compter le nb d'éléments
	var nb:int=tabPhotos.push(e.target.loader);
	if (nb<=nbPhotos) {
		// charger le suivant
		charge("P"+nb+".jpg");
	} else {
               // On a tout 
		trace("prêt à déclencher les hostilités : "+ tabPhotos)
	}
}

prêt à déclencher les hostilités : [object Mv_Photo0],[object Loader],[object Loader],[object Loader]

Fabriquer le masque

La technique mise en œuvre pour la transition c'est une animation, un clip utilisé comme masque pour dévoiler la photo suivante. Vous pouvez réutiliser celui que vous avez construit ici, pensez seulement à supprimer les images après les interpolations qui n'étaient destinées qu'à permettre un temps d'exposition entre deux photos, on va bien sûr se faire une joie de coder une propriété temps_de_pause

La Classe

Préparer la classe et vérifier que "jusque là, ça va".

On a tout ce qu'il faut pour agencer les premières briques de notre gros lego perso. Je vous laisse construire la structure de base de la classe : un constructeur qui trace ses deux paramètres (pTabVisuels, et pMasque) et les deux méthodes marche et arret.
Ici elle se nomme VisioPazapa, faites bien comme vous voulez de votre côté.

// .as
 
package {
	import flash.display.MovieClip;
 
	public class VisioPazapa extends MovieClip {
 
		public function VisioPazapa(pTabVisuels:Array, pMasque:MovieClip):void {
			trace("constructeur visio : " + pTabVisuels + "\nmasque : "+pMasque);
		}
 
		public function marche():void {
			trace("Marche");
		}
 
		public function arret():void {
			trace("Arrêt");
		}
 
	}
}

… et on vérifie immédiatement que tout se déroule comme prévu : une fonction nouvelleVisionneuse (appelée dans fini) qui crée et ajoute une instance de notre classe toute neuve.

// .fla
 
var ldrFichier:Loader;
var ldrInfo:LoaderInfo;
 
var tabPhotos:Array=new Array();
var nbPhotos:int=3;
 
// déclarer un objet VisioPazapa
var visio:VisioPazapa;
 
var visuelDep:Mv_Photo0= new Mv_Photo0();
tabPhotos.push(visuelDep);
 
 
for (var i:int=1; i<=nbPhotos; i++) {
	ldrFichier= new Loader();
	ldrInfo=ldrFichier.contentLoaderInfo;
	ldrInfo.addEventListener(Event.COMPLETE, fini);
	ldrFichier.load(new URLRequest("P"+i+".jpg"));
}
 
function fini(e:Event) {
	var nb:int=tabPhotos.push(e.target.loader);
	if (nb>nbPhotos) {
		trace("prêt à déclencher les hostilités : " +tabPhotos);
                // création de la visionneuse
		nouvelleVisionneuse();
	}
}
// 
function nouvelleVisionneuse() {
        // créer un objet Mv_Masque0
        var leMasque:Mv_Masque0=new Mv_Masque0();
        // nouvelle instance initialisée avec le tableau et le masque
	visio=new VisioPazapa(tabPhotos,leMasque);
        // ajouter à la liste d'afichage
	addChild(visio);
}

prêt à déclencher les hostilités : [object Mv_Photo0],[object Loader],[object Loader],[object Loader]
constructeur visio : [object Mv_Photo0],[object Loader],[object Loader],[object Loader]
masque : [object Mv_Masque0]

Ajouter le masque

Pas très visuel tout ça… Oui on dispose bien de tout l'attirail nécessaire : un clip futur masque et un tableau d'images, mais bon… on en fait quoi ?
Dans un premier temps on ajoute le masque, ensuite on s'occupera des couples de visuels.

Comme on imagine bien qu'on aura besoin du masque et du tableau d'un peu partout dans la classe (pas uniquement depuis le constructeur à l'initialisation), on sort deux globales privées : masque et tabVisuels. On applique un flou au masque, on l'ajoute à la liste d'affichage.

	import flash.display.MovieClip;
	import flash.filters.BlurFilter;
	import flash.filters.BitmapFilterQuality;
 
	public class VisioPazapa extends MovieClip {
 
		private var tabVisuels:Array;
		private var masque:MovieClip;
 
		public function VisioPazapa(pTabVisuels:Array, pMasque:MovieClip):void {
			trace("constructeur visio : " + pTabVisuels + "\nmasque : "+pMasque);
			tabVisuels=pTabVisuels;
			masque=pMasque;
			masque.gotoAndStop(2);
			masque.filters=[new BlurFilter(10,10,BitmapFilterQuality.HIGH)];
			addChild(masque);
		}

Ça c'est fait.

Qu'on prenne soin d'arrêter la lecture du clip masque dès tout de suite ça ne vous surprend pas, en revanche que j'utilise un gotoAndStop(2), là vous vous dites : elle fatigue la malheureuse !…
Et bien non ! Pour l'instant le stop que vous avez probablement écrit convient tout à fait, mais plus tard il risque de nous envoyer droit dans le mur… On y reviendra… (suspens… tada ! )

Afficher les visuels

Le masque c'est fait, il ne reste plus qu'à afficher une paire de visuels, un pour le fond, un autre qui sera dévoilé (masqué par masque). On va s'en débrouiller dans une fonction chargeVisuels, appelée dans le constructeur.

		public function VisioPazapa(pTabVisuels:Array, pMasque:MovieClip):void {
			tabVisuels=pTabVisuels;
			masque=pMasque;
			masque.gotoAndStop(2);
			masque.filters=[new BlurFilter(10,10,BitmapFilterQuality.HIGH)];
			addChild(masque);
                        // les visuels
                        chargeVisuels()
		}

La fonction chargeVisuels

C'est le même principe que détaillé ici, je ne recommence pas ^^

		private function chargeVisuels():void {
			var idxTmp:int=idxSup;
 
			try {
				removeChild(photoFond);
				removeChild(photoRecouvre);
			} catch (e:Error) {
			}
			//au premier passage idxSup = 1 et idxInf = 0;
			photoRecouvre=tabVisuels[idxSup];
			photoFond=tabVisuels[idxInf];
 
			photoRecouvre.mask=_masque;
			photoRecouvre.cacheAsBitmap=true;
			addChildAt(photoRecouvre,0);
			addChildAt(photoFond,0);
 
                        // incrémenter pour le prochain passage
                        idxSup++;
                        // idxSup vaut 1 si supérieur à numPhotoMax 
			idxSup=idxSup>numPhotoMax?1:idxSup;
			idxInf=idxTmp;
		}

Bien sûr, il faut avoir déclaré et valorisé les variables :

		private var idxSup:int=1;
		private var idxInf:int=0;
		private var numPhotoMax:int;
 
		private var photoFond:DisplayObject;
		private var photoRecouvre:DisplayObject;
 
                //[.....]
 
                public function VisioPazapa(pTabVisuels:Array, pMasque:MovieClip):void {
			trace("constructeur visio : " + pTabVisuels + "\nmasque : "+pMasque);
			NumPhotoMax=pTabVisuels.length-1;
 
                //[.....]

… et avoir importé la classe.

	import flash.display.DisplayObject;

On devine bien le visuel d'index 1 derrière l'instance de Mv_Photo0.

La transition

C'est le moment de faire en sorte que les méthodes marche et arrêt fassent autre chose que tracer une bête ligne.

		public function marche() {
			masque.play();
		}
		public function arret() {
			masque.stop();
		}

Dans l'absolu, il suffit maintenant d'ajouter un écouteur à visio et d'écrire une jolie bascule :

function nouvelleVisionneuse() {
	visio=new VisioPazapa(tabPhotos,leMasque);
	visio.addEventListener(MouseEvent.CLICK,marcheArret);
	addChild(visio);
}
//
function marcheArret(me:MouseEvent) {
	if (visio.enMarche) {
		visio.arret();
	} else {
		visio.marche();
	}
}

Râle pas Ronchon ! Non il n'y a pas de propriété enMarche définie dans la classe, mais il faut bien anticiper : puisqu'il est évident qu'on en aura besoin on considère qu'elle existe et, tout de suite derrière, on file dans la classe l'ajouter d'un couple d'accesseurs comme on sait les faire.

		public function set enMarche(pB:Boolean):void {
			_enMarche=pB;
		}
		public function get enMarche():Boolean {
			return _enMarche;
		}

Avec la globale :

		private var _enMarche:Boolean=false;

Puis on s'occupe de modifier la valeur de cette variable dans les méthodes marche et arret :

		public function marche(e:Event=null) {
			trace("marche");
			masque.play();
			_enMarche=true;
		}
		public function arret() {
			trace("arret");
			masque.stop();
			_enMarche=false;
		}

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.

Et là, youpi ! Ça dévoile

Enchainer les images

La belle affaire… Ce qu'on veut c'est qu'à chaque fois que la lecture du masque boucle (revient image 1), un nouveau couple d'image soit chargé… Il faudrait un petit script image 1… il faudrait ajouter à l'instance masque, image 1, un script qui appèlerait chargeVisuels… ! addFrameScript, bien sûr.
En se souvenant que la première image est numérotée zéro, ça donne :

  masque.addFrameScript(0,chargeVisuels);

On ajoute la ligne dans le constructeur.

		public function VisioPazapa(pTabVisuels:Array, pMasque:MovieClip):void {
			NumPhotoMax=pTabVisuels.length-1;
			tabVisuels=pTabVisuels;
			masque=pMasque;
			masque.gotoAndStop(2);
			masque.filters=[new BlurFilter(10,10,BitmapFilterQuality.HIGH)];
			// ajouter du code image 1 de masque
			masque.addFrameScript(0,chargeVisuels);
			addChild(masque);
                        chargeVisuels();
		}

Et c'est là qu'on est content d'avoir anticipé le gotoAndStop(2).
Hé oui, la méthode addFrameScript recèle bien des surprises quand on l'applique à une image de clip qui se trouve être l'image courante… Je ne vous cache pas que j'ai bien failli y laisser mon intégrité mentale (je synthétiserai plus loin). Pour éviter de nous compliquer la vie, avoir pris soin d'arrêter la tête de lecture image deux, est une ruse qui vaut ce qu'elle vaut, mais garantit un déroulement des choses sur lequel on a vraiment la main
Du coup, soit on appelle chargeVisuels comme ci-dessus, soit on renvoie la tête de lecture image 1 et la fonction chargeVisuels fraichement associée est invoquée (c'est la version des sources).

masque.gotoAndStop(1);

Et voilà une visionneuse, spartiate, mais tout à fait fonctionnelle…

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.

Bien sûr on peut souhaiter quelques sophistications supplémentaires : changer le sens de défilement, paramétrer le temps de pause entre deux visuels, atteindre directement un visuel, disposer d'événements pour intercepter le moment où le diaporama boucle, où le changement d'image à lieu…

page suivante -->

zip : fla/as
zip : les trois jpg

Classe de document

Nataly — Mon, 26 Jul 2010 17:31:47 +0200

Introduction
Classe de base (#1)
Classe de base (#2)
Héritage et surcharge (#1)
Héritage et surcharge (#2)
Diffuser des événements
Classe liée
Classe de document
Classe externe : une visionneuse (#1)
Classe externe : une visionneuse (#2)
Classe externe : méthodes statiques

Classe de document

Et nous voilà arrivés à l'incontournable classe de document. Vous la connaissez déjà c'est sûr, ne serait-ce que de réputation, on en voit partout, à commencer par la doc.
Rassurez vous, ça va aller vite, on a déjà quasi tout vu quant aux classes, il ne reste que quelques point spécifiques à ce cadre d'utilisation à préciser.

Commençons par le début, il s'agit donc une classe destinée à être associée, non pas à un symbole, comme nous l'avons fait jusqu'alors mais au fichier (document) .fla lui même.
Dire “associer une classe au fichier” c'est un abus de langage, en vrai c'est “associer une classe au 'clip racine' de l'animation” qu'il faudrait dire. Je m'explique :
Il ne faut pas perdre de vue que le scénario principal n'est en fin de compte qu'un gros clip qui constitue l'animation elle même. Un gros clip donc, qui en contient d'autres ainsi que divers éléments (composants, champs texte, formes…). C'est ce clip qui vaut this (depuis une image du scénario principal) et c'est toujours ce clip qui est renvoyé par la propriété root de n'importe quel objet de l'animation. C'est un clip unique, une instance de MainTimeline. Tracez this si vous voulez vérifier.

[object MainTimeline]

Quand une animation (.swf) est lue dans le lecteur, ce clip scénario principal (mainTimeline) est ajouté à la scène (stage).
D'ailleurs vous pouvez le supprimer de la liste d'affichage :

stage.removeChild(this)

Ça ne sert à rien d'autre que tranquilliser les St Thomas

• Au même titre qu'on peut associer une classe à un clip de bibliothèque, on peut associer une classe au gros clip scénario-principal (main timeline en anglais). Cette casse répondra aux mêmes exigences syntaxiques que n'importe quelle classe et devra étendre la classe MovieClip ou Sprite selon que nous aurons recours ou non aux méthodes spécifiques de gestion de scénario ( stop, play…).

• Au même titre que, comme nous l'avons vu précédemment, tout ce qui pourrait s'écrire dans la première image d'un clip peut s'écrire dans une classe associée, tout ce qui peut s'écrire dans la première image du scénario principal peut être écrit dans sa classe associée en tant que classe du document.

Utiliser les exemples de la doc

Je vous propose d'expérimenter le principe à partir d'un cas fréquent : un paquetage illustrant un point quelconque de la documentation, ensuite on verra comment fabriquer nos propres classes de document, mais en fait vous savez déjà

Imaginons que nous consultions la rubrique ColorTransform.
La page
Tout en bas de la page un exemple prêt à l'emploi :

package {
    import flash.display.Sprite;
    import flash.display.GradientType;
    import flash.geom.ColorTransform;
    import flash.events.MouseEvent;
 
    public class ColorTransformExample extends Sprite {
        public function ColorTransformExample() {
            var target:Sprite = new Sprite();
            draw(target);
            addChild(target);
            target.useHandCursor = true;
            target.buttonMode = true;
            target.addEventListener(MouseEvent.CLICK, clickHandler)
        }
        public function draw(sprite:Sprite):void {
            var red:uint = 0xFF0000;
            var green:uint = 0x00FF00;
            var blue:uint = 0x0000FF;
            var size:Number = 100;
            sprite.graphics.beginGradientFill(GradientType.LINEAR, [red, blue, green], [1, 0.5, 1], [0, 200, 255]);
            sprite.graphics.drawRect(0, 0, 100, 100);
        }
        public function clickHandler(event:MouseEvent):void {
            var rOffset:Number = transform.colorTransform.redOffset + 25;
            var bOffset:Number = transform.colorTransform.redOffset - 25;
            this.transform.colorTransform = new ColorTransform(1, 1, 1, 1, rOffset, 0, bOffset, 0);
        }
    }
}

Pour tester, comme précisé dans la doc elle même, il nous faudra un fichier as pour la classe et un fla auquel l'associer.

On note que la classe s'appelle ColorTransformExample, ce sera donc le nom du fichier as que nous enregistrerons dans le même répertoire que le fla de test.

Quant au fichier fla, pour préciser l'association il suffit de saisir le nom de la classe en question dans le panneau propriétés dans le champ Classe.

Si vous avez collé le code dans le fichier as et enregistré vous pouvez constater qu'à l'exécution du fla il se passe quelque chose.
C'est un bon début.

Quand ça va mal

Mais peut-être rencontrez vous déjà un problème, sous forme de message d'erreur à la compilation :
ColorTransformExample.as, ligne 1 1180: Appel à une méthode qui ne semble pas définie, addFrameScript.
Il suffit que vous ayez écrit une malheureuse ligne de code dans le fla, un simple trace, voire une ligne commentée, voire pire : quelques lignes vierges… Si, si, essayez :

Ça suffit à le faire crier !!

Que se passe-t-il ?
Regardons la définition de classe :

public class ColorTransformExample extends Sprite {

Elle étend la classe Sprite.
Un objet Sprite est similaire à un clip, mais ne possède pas de scénario. C'est la doc qui le dit, j'ajoute et précise que par conséquent il n'expose pas les méthodes et propriétés de gestion de scénario spécifiques à la classe MovieClip, telles play, stop et autre currentLabel. Une autre méthode spécifique à MovieClip c'est addFrameScript. Non documentée, elle permet d'ajouter du code dynamiquement à une une image. Le fait d'écrire dans le panneau action est manifestement traduit par l'appel à cette fameuse fonction, d'où le message d'erreur. Ce qui est plus surprenant, je vous l'accorde, c'est de constater que même une ligne vierge est comprise comme code… Bon, c'est comme ça, il faut le savoir voilà tout

Pour se débarrasser du problème il suffit de prendre soin de ne rien écrire du tout dans le panneau action, ou d'étendre la classe MovieClip.

  public class ColorTransformExample extends MovieClip {

… et bien sûr d'importer la classe

  import flash.display.MovieClip;

Ainsi, nous disposons de sources fonctionnelles qu'il suffit d'associer à un document .fla pour les tester, exactement comme si on avait récupéré un .fla avec du code. Vu qu'il est plus simple de fournir du texte qu'un .fla, on trouve très souvent des sources sous cette forme.

Comme par ailleurs il est souvent préconisé d'étendre la classe Sprite chaque fois qu'on n'a pas besoin du scénario (quand tout se passe dans une seule image), il n'est pas rare de trouver des sources sous forme d'un fichier .as étendant la classe Sprite. Si vous voulez ajouter votre propre code au fla, ou seulement y noter des infos sous forme de commentaires vous devrez modifier la-dite classe afin qu'elle étende MovieClip.

Ça devient vite pénible de devoir doubler les fichiers (le .fla plus le .as) à chaque fois qu'on a besoin de tester trois lignes. Rien ne vous empêche de prélever la fonction qui vous intéresse et de la coller dans le fla.
Par exemple ici, que fait le paquetage fourni par la doc ?
Il dessine un carré dégradé et quand on clique dessus la fonction clickHandler est invoquée et applique le fameux ColorTransform à this (vite dis).

        public function clickHandler(event:MouseEvent):void {
            var rOffset:Number = transform.colorTransform.redOffset + 25;
            var bOffset:Number = transform.colorTransform.redOffset - 25;
            this.transform.colorTransform = new ColorTransform(1, 1, 1, 1, rOffset, 0, bOffset, 0);
        }

On est bien d'accord que le scénario c'est this ? On l'a vu en intro, associer une classe à un document c'est en fait associer une classe au gros clip principal que constitue l'animation. Pour vous en convaincre dessinez une forme sur la scène et testez.
On constate que la couleur de cette forme elle aussi est modifiée au clic. Normal : c'est tout l'objet TimeLine qui fait l'objet du ColorTransform, donc tout ce qu'on pose sur la “scène”. Souvent on dit par abus de langage qu'on dessine une forme, ou qu'on pose un clip directement sur la scène. En fait il s'agit toujours du scénario, qui lui même est ajouté à la scène à la lecture.

Pour en revenir à nos moutons, dans le cas qui nous intéresse (tester la fonction clickHandler) on pourrait tout aussi bien la coller dans le fla et l'appeler au clic d'un bouton (voire de la scène pour les plus fainéants) :

stage.addEventListener(MouseEvent.CLICK, clickHandler);
 
function clickHandler(event:MouseEvent):void {
	var rOffset:Number=transform.colorTransform.redOffset+25;
	var bOffset:Number=transform.colorTransform.redOffset-25;
	this.transform.colorTransform=new ColorTransform(1,1,1,1,rOffset,0,bOffset,0);
}

Tout ce qu'on a dessiné sur le scénario - avec les couleurs de notre choix pour bien comprendre - sera modifié à chaque clic…
Pensez bien à supprimer l'attribut public devant la fonction, il n'a de raison d'être qu'au sein d'un paquetage. D'ailleurs le message d'erreur est on ne peut plus explicite :
1114: L'attribut public ne peut être utilisé que dans un package.

Créer sa propre Classe de document

Pourquoi décider d'écrire un fichier as plutôt que dans le fla ?

• Parce que vous avez envie.
• Pour donner les sources à quelqu'un facilement sur le forum
• Pour pouvoir éditer son code dans un éditeur digne de ce nom. (Je dénonce : c'est Lilive qui le précise).
• Parce que vous anticipez un moteur commun à plusieurs animations. Ça c'est le motif qui vaut que je développe un peu :
Imaginons que vous ayez à réaliser une série de quizz, chacun d'eux sous forme d'un .swf différent. Tous ces quizz auront en commun la gestion même du questionnaire : passer à la question suivante seulement si une réponse a été faite dans la question courante (sinon une jolie boite d'alerte modale ), calculer le score, avertir en cas de reprise avant la fin de la série de questions (autre jolie boite modale type Oui/Non : “Votre score est de x, voulez vous vraiment reprendre à zéro”), etc.
Mais chaque quizz aura ses particularités, des questions différentes pour commencer, mais aussi une charte graphique, des illustrations et autres fioritures…
Il pourrait être intéressant d'avoir une classe de document Quizz.as qui s'occupe de ce qui est commun, il n'y aurait plus qu'à l'associer à chaque nouveau .fla sans plus se préoccuper de quoique ce soit d'autre que du graphisme…

Gestion du scénario

Un petit exemple vite fait de classe de document, histoire de nous entrainer. Une classe destinée à une animation qui utilise le scénario, tant qu'à faire…

Imaginons image 1 du scénario un champ de saisie, si la saisie est valide, l'animation est lue (joli effet) et s'arrête sur la dernière image, là on affiche un truc reprenant la saisie.
L'exemple n'est destiné qu'à illustrer les quelques points qui ont à voire avec la gestion du scénario.

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.

Il vous faut donc un .fla minimaliste avec un champ de saisie image 1, une zolie animation jusqu'à image 30 (par exemple) et sur cette image un nouveau champ texte dynamique.
Il vous faut aussi une classe destinée à être associée. Pour une fois je ne vais pas jouer la francophone forcenée, d'accord, on l'appelle main (mais maitre ça allait aussi ).

Les deux classes dans le même répertoire, comme d'habitude. Si vous souhaitez vous organiser autrement, maintenant vous savez faire. Si la classe est incluse dans paquetage, il faudra tout écrire :

Préparons le travail, le fichier .as :

// ******** Requiert **************
// btValide : Bouton - image 1
// txtPseudo : textField - image 1
// txtNom : TextField - dernière image
//******************************
 
package {
 
	import flash.display.MovieClip;
 
	public class main extends MovieClip {
 
		public function main():void {
                    trace("passage dans main")
 
		}
	}
}

Bien sûr, on étend MovieClip puisqu'on compte lire le scénario, et on importe la classe.

Ne confondez pas…

Une fois la classe main associée au .fla via le champ Classe du panneau de propriété, on peut tester… Ce n'est pas bien satisfaisant, ça boucle (normal on n'a rien fait) mais bon, ça ne crie pas et c'est un bon début. Et puis aussi vous constatez que la fonction constructeur n'est invoquée qu'une fois. Je disais en introduction que tout ce qu'on écrit image 1 d'un fla peut tout aussi bien être écrit dans une classe, c'est toujours vrai, mais constatez tout de même la différence entre constructeur (initialisation) et action d'image. Si image 1 du .fla vous écrivez un trace(“Je passe”), la fenêtre de sortie affiche son “je passe” à chaque boucle, alors que le constructeur n'est invoqué qu'une fois.

Notez aussi au passage (si je peux dire) que le constructeur est invoqué avant les actions d'image de l'image 1

Première chose, arrêter la lecture :

		public function main():void {
			stop();
			trace("costructeur");
		}

C'est presque la même chose que le stop qu'on pose image 1.
Vous voyez pourquoi je dis presque ?

Lançons la lecture au clic sur le bouton :

		public function main():void {
			stop();
			trace("costruc");
			btValide.addEventListener(MouseEvent.CLICK,valide);
		}
		private function valide(me:MouseEvent) {
			play();
		}

Là c'est clair ! Un stop image 1 aurait de nouveau arrêté la lecture dès le retour image 1. Ici il n'y est pas, ça boucle donc sans discontinuer, normal, mais j'en connais qui s'y sont laissé prendre

La liste d'affichage

Occupons nous maintenant d'écrire le contenu du champ txtPseudo (image 1) dans txtNom image 30 (la dernière)

Mauvaise idée :

		private function valide(me:MouseEvent) {
			gotoAndStop(30);
                        txtNom.text="Ça marche "+txtPseudo.text;
		}

Effectivement, image 30 il n'y a plus txtPseudo… A la lecture de chaque image la liste d'affichage est modifiée : n'y figurent que les objets présents sur l'image courante, mais vous le saviez… C'est juste dans le cadre du “ce qui va sans dire va toujours mieux en le disant”

		private function valide(me:MouseEvent) {
			var leNom:String=txtPseudo.text;
			gotoAndStop(30);
			txtNom.text="Ça marche "+leNom;
		}

Ça c'est déjà mieux, et dans un contexte de réalité on sortirait sans doute la variable pour pouvoir y accéder de partout par la suite.

package {
 
	import flash.display.MovieClip;
 
	public class main extends MovieClip {
		private var leNom:String
 
		public function main():void {
			stop();
			trace("costruc");
			btValide.addEventListener(MouseEvent.CLICK,valide);
		}
		private function valide(me:MouseEvent) {
			leNom=txtPseudo.text;
			gotoAndStop(30);
			txtNom.text="Ça marche "+leNom;
		}
	}
}

Ça, c'est carrément bien : une variable globale (visible de partout dans la classe) et privée (c'est de la cuisine interne, on n'y accèdera pas depuis le fla).

Ajouter des actions d'image

D'accord j'accélère, j'en vois qui s'impatientent…
La vraie question c'est comment lancer la lecture (play) pour lire la belle animation, et s'arrêter image 30 pour y écrire leNom.

La solution passe par la fameuse méthode non documentée addFrameScript. Elle admet deux paramètres, le premier le numéro de l'image, le second une fonction qui sera invoquée à la lecture de l'image en question.
Les images sont numérotées depuis zéro.

unClip.addFrameScript(19,test)

… invoquera la fonction test image 20

Ce que vous auriez écrit dans l'action d'image, vous l'écrivez dans le bloc de la fonction, c'est aussi simple et pratique que ça

		public function main():void {
			stop();
			trace("costruc");
			addFrameScript(totalFrames-1,fin);
			btValide.addEventListener(MouseEvent.CLICK,valide);
		}
		private function fin() {
			trace("fin");
			stop();
			txtNom.text="Ça marche "+leNom;
		}
		private function valide(me:MouseEvent) {
			leNom=txtPseudo.text;
			play();
		}

Tant qu'à faire on ajoute le code non pas image 30 mais sur la dernière image, ça nous permettra de modifier la durée de l'animation si le cœur nous en dit

Utiliser des clips associés à une classe

Juste pour le plaisir d'utiliser notre nouvelle classe BoiteAlerte, vérifions que txtPseudo n'est pas vide avant de lancer la lecture.

Il nous faut donc un symbole qui sera lié à la classe BoiteAlerte, si vous ne vous souvenez plus des caractéristiques requises par la classe, ouvrez là et lisez votre pense bête que vous n'avez pas manqué d'insérer tout en haut

// ******** requiert ******************
//btOK : bouton
//txtPrompt : TextField 
//*************************************

Vous pouvez aussi copier/coller le symbole de l'exercice précédent

Le code depuis le fla, vous savez faire. Là c'est pareil…

// ******** Requiert **************
// btValid : Bouton
// txtPseudo : textField - image 1
// txtNom : TextField - dernière image
//******************************
package {
 
	import flash.display.MovieClip;
	import flash.events.MouseEvent;
 
 
	public class main extends MovieClip {
		private var leNom:String;
        // ---> déclaration/valorisation de la variable 
		var bteAlerte:Mv_BoiteAlerte=new Mv_BoiteAlerte();
 
		public function main():void {
			stop();
			addFrameScript(totalFrames-1,fin);
			btValide.addEventListener(MouseEvent.CLICK,valide);
		}
		private function fin() {
			stop();
			txtNom.text="Ça marche "+leNom;
		}
		private function valide(me:MouseEvent) {
                //--> interception
                	if (txtPseudo.text=="") {
                                // "réglages"
				bteAlerte.racine=root;
				bteAlerte.prompt="Le champ ne doit pas être vide";
				bteAlerte.x=(stage.stageWidth-bteAlerte.largeurBoite)/2;
				bteAlerte.y=63;
				bteAlerte.coulEcran=0xFF0000;
                                // afficher
				bteAlerte.affiche();
				return;
			}
			leNom=txtPseudo.text;
			play();
		}
	}
}

Et voilà le travail

Pour résumer

Une classe de document doit impérativement étendre la classe Sprite ou MovieClip.
On peut étendre Sprite quand on n'utilisera pas le scénario (une seule image), et on sait qu'on ne pourras rien écrire dans les actions d'image du fla associé, même pas un commentaire.
Dit autrement : étendre MovieClip, ça marche toujours ; étendre Sprite c'est soumis à contrainte.

Le constructeur de la classe est invoqué avant les actions d'image 1 et ce n'est pas la même chose.

Seuls les objets d'affichage de l'image courante du scénario sont présents dans la liste d'affichage.

Passer d'un .fla à un .as (et vices inversés)

Pour en finir avec ce chapitre, et puisqu'il est fréquent de disposer d'une classe document alors qu'on souhaite rester dans l'ide et pas si rare de s'apercevoir en cours de travail sur le fla, que tous comptes faits, une classe conviendrait mieux, voici le même code selon les deux versions :

On considère un champ texte txtSortie et un bouton btDemo.

[mode vieille chose] … et n'allez pas imbriquer toutes les fonctions dans le constructeur … [/mode]

Mais… Du coup…

Nous voici donc au point pour ce qui est de la classe de document, classe destinée à être associée au gros clip racine qu'est l'objet MainTimeline.

Et si on associait une classe de document à un “petit clip normal” de la bibliothèque ? Ça ferait quoi ?
Et bien pareil

Un clip c'est un clip, qu'il s'agisse du scénario principal ou d'un clip de bibliothèque, il hérite de la même classe (ouf…) et se comporte pareil (re ouf !). Le dernier exemple de classe que nous avons mis en œuvre ici présuppose qu'il existe à la racine du projet image 1, un champ de saisie et un bouton. Il présuppose aussi un autre champ texte sur la dernière image. Sachez que n'importe quel clip qui respecte ces prérequis pourra tout aussi bien être associé à cette classe.

Ce qui implique que rien ne nous oblige à exploiter une classe de document (trouvée sur le net par exemple) en tant que telle. Imaginons une classe de document qui mette en œuvre un carrousel, ou un menu Dock. L'associer à un un .fla pour la tester c'est bien, mais dans la pratique, on n'aura jamais besoin uniquement de ce menu, il viendra s'intégrer au reste de l'animation (un site probablement). Un peu compliqué, non, d'en faire un swf qui sera chargé et exploité dans un autre .fla ?
On pourra fort bien associer la classe à un symbole de la bibliothèque, en profiter pour enrichir ce symbole des éléments graphiques de notre goût (fond et fioritures) et en disposer une instance sur la scène.

Cette fois, c'est définitivement tout pour ce qui concerne les classes que j'ai dites “relatives à un fichier fla” en introduction. Il ne nous reste plus qu'à voir ce qui concerne les autres classes, celles que j'ai dites génériques dans cette même introduction.

C'est par là que ça se passe.

Classe liée

Nataly — Mon, 26 Jul 2010 17:31:01 +0200

Introduction
Classe de base (#1)
Classe de base (#2)
Héritage et surcharge (#1)
Héritage et surcharge (#2)
Diffuser des événements
Classe liée
Classe de document
Classe externe : une visionneuse (#1)
Classe externe : une visionneuse (#2)
Classe externe : méthodes statiques

Classe liée

Une classe liée, c'est la même chose qu'une classe de base, si ce n'est qu'on ne peut pas lier plusieurs symboles à la même classe comme on la vu ici.

Quel intérêt alors ?

L'intérêt principal c'est que ça mène tout droit au composant , l'intérêt second c'est qu'on peut l'initialiser à la création, en utilisant addChild.
Débarrassons nous de cette histoire d'initialisation, ensuite on jouera à transformer un symbole lié à une classe en composant… Oui, oui, vous avez bien entendu, on peut le faire (Bonus !).

Exemple avec la classe SimpleButton

Plutôt qu'illustrer ce chapitre avec un symbole clip, nous allons le faire avec un symbole bouton. D'une pierre deux coups

Puisque l'intérêt de la classe liée c'est de permettre l'initialisation à la création (mot clé new) considérons le cas typique suivant : on voudrait un beau bouton, avec graphisme maison qui déchire tout et un champ texte pour y écrire l'intitulé du bouton.

Ensuite on pourrait ajouter autant d'instances (occurrences) que nécessaire comme suit :

var btAcceuil:BoutonPerso=new BoutonPerso("Accueil");
var btInfo:BoutonPerso=new BoutonPerso("Qui sommes nous ?");
var btProduits:BoutonPerso=new BoutonPerso("Nos Produits");
Menu.addChild(btAccueil)
btAccueil.y=0;
Menu.addChild(btInfo);
btAccueil.y=55;
// etc…

La classe

Commençons par la classe, ensuite on fera le bouton qu'on y associera. (Si vous avez envie de jouer à faire du beau bouton tout de suite, retenez vous : vous seriez obligés de tout recommencer dès l'étape suivante).

Comme d'habitude, classe et fichier fla de test doivent être dans le même répertoire (on a vu comment s'organiser autrement là). En fait, vous savez la construire cette classe, ça obéit aux mêmes règles que ce que nous venons de voir (une chance), donc même modèle qu'une classe de base, si ce n'est que dans le cas qui nous occupe, il s'agit d'étendre non pas la classe MovieClip, mais la classe SimpleButton, et donc d'importer non pas flash.display.MovieClip, mais flash.display.SimpleButton.

L'information est dans la doc. Posez le curseur dans votre code sur SimpleButton, enfoncez la touche F1, regardez tout en haut :
Package flash.display
Classe public class SimpleButton

Allez, zou ! Un fichier .as, un package, dedans une classe, dedans un constructeur, un trace pour tester…

package {
	import flash.display.SimpleButton;
	public class BoutonPerso extends flash.display.SimpleButton {
 
		public function BoutonPerso():void {
			trace("constructeur BoutonPerso");
		}
	}
}

Le .fla

Du côté du fla, dans la bibliothèque, un bouton avec une forme et un champ texte : txtTitre (faites simple surtout, c'est très provisoire), case exporter pour ActionScript cochée, champ Classe renseigné du nom de la classe (ici BoutonPerso).

Dans le panneau action de l'image 1 de la scène :

var bouton1:BoutonPerso=new BoutonPerso ();
addChild(bouton1);
bouton1.x=bouton1.y=50;

Testez, jusque là rien de neuf. On a dit que l'intérêt de la classe liée c'est l'initialisation à la création. Allons y donc, ajoutons un paramètre au constructeur :

// la classe
public function BoutonPerso(pTitre:String):void {
	trace("constructeur BoutonPerso "+pTitre);
}

//le fla
var bouton1:BoutonPerso=new BoutonPerso ("Coucou");
addChild(bouton1);
bouton1.x=bouton1.y=50;

Plus rien pour vous surprendre, si ce n'est que ça crie quand on a le culot de poser directement une instance sur la scène :
ArgumentError: Error #1063: Non-correspondance du nombre d'arguments sur BoutonPerso(). 1 prévu(s), 0 détecté(s).
Suivi de tout un tas d'insanités…

Normal, l'instance posée sur la scène invoque le constructeur sans argument (comment ferait-elle ?) or le constructeur en prévoyait un…
Qu'à cela ne tienne, il suffit de le rendre facultatif en précisant une valeur par défaut.

public function BoutonPerso(pTitre:String="truc"):void {

Nous voilà parés.

Qui vous savez s'énerve derrière son clavier. Lui il veut écrire le titre dans le champ texte, c'est bien le but non ? Et bien pas possible, ce fichu machin prétend qu'il n'y pas de champ texte nommé txtTitre… Ça fait dix fois qu'il vérifie, bien sûr que si !

Les états de bouton

En effet :

public function BoutonPerso(pTitre:String="truc"):void {
	trace(this);
	trace(this.txtTitre);
}

… nous renvoie :

[object BoutonPerso]
null

Il est pas gonflé lui… Mais, null toi même !

En fait c'est à cause de cette particularité des boutons qui veut qu'ils présentent différents visuels selon la position/action de la souris. Dans l'ide les images sont nommées Haut, Dessus, Abaissé et Cliqué. C'est ce qu'on appellera ici les états.
On accède aux états à l'aide des propriétés upState, overState, downState et hitTestState qui renvoient un objet d'affichage utilisé comme visuel associé à l'état considéré
Concrètement, il va s'agir pour nous de regrouper le visuel de chacun des états dans un clip, ensuite nous pourrons accéder au contenu via la propriété idoine.

Pour commencer contentons nous de construire un clip pour l'état Haut (chez moi Mv_EtatHaut). Il contiendra a minima une forme et un champ texte nommé txtTitre (vous pouvez tout bonnement convertir ce que vous avez avec F8 après avoir sélectionné la forme et le champ texte).

On peut maintenant récupérer le clip via la propriété upstate qui renvoie un displayObject de type MovieClip

	public function BoutonPerso(pTitre:String="truc"):void {
		trace("upstate : "+this.upState);
	}

upstate : [object MovieClip]

Et on accède à txtTitre tout normalement (en ayant pris soin de transtyper en MovieClip) :

	public function BoutonPerso(pTitre:String="truc"):void {
		trace("upstate : "+this.upState);
		trace("txtTitre "+MovieClip(upState).txtTitre);
		MovieClip(upState).txtTitre.text=pTitre;
	}

upstate : [object MovieClip]
txtTitre [object TextField]

On pause une instance sur la scène et comme on l'espérait, à l'exécution le champ texte affiche “truc”, la valeur par défaut.

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.

Les deux autres états (survol et abaissé) affichent “pour voir”, normal c'est ce qu'on avait mis dans le champ texte du symbole, justement pour y voir quelque chose.
Ce qui peut décontenancer, c'est de constater que même si seule l'image Haut contient un visuel (comme sur la copie d'écran) les deux autres états affichent tout de même quelque chose. C'est comme ça, c'est à savoir : si seul l'état Haut (upState) a été crée dans symbole, le lecteur le duplique pour les deux autres états. De la même manière si l'état Abaissé (downState) n'a pas été crée, c'est l'état Dessus (overState) qui est dupliqué.

Finitions :
Libre à vous maintenant de créer les autres clips pour faire les visuels des états survol et abaissé. Il faudra bien sûr avoir recours aux propriétés overState et downState pour initialiser le champ de texte.
Par ailleurs, puisque on a prévu l'éventualité où les boutons seraient posés directement sur la scène il faut faire en sorte qu'ils puissent afficher autre chose que truc (la valeur par défaut). Il nous faut une propriété titre, donc un couple d'accesseurs comme vous savez les faire maintenant

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.

// mise en œuvre fla
 
// bt1 sur la scène
bt1.titre="Accueil";
 
// une instance ajoutée dynamiquement
var bouton1:BoutonPerso=new BoutonPerso ("Infos");
addChild(bouton1);

package {
	import flash.display.SimpleButton;
	import flash.display.MovieClip;
 
	public class BoutonPerso extends flash.display.SimpleButton {
		private var _titre:String;
		public function BoutonPerso(pTitre:String=""):void {
			_titre=pTitre;
			MovieClip(upState).txtTitre.text=_titre;
			MovieClip(downState).txtTitre.text=_titre;
			MovieClip(overState).txtTitre.text=_titre;
		}
		public function set titre(pTitre:String):void {
			_titre=pTitre;
			MovieClip(upState).txtTitre.text=_titre;
			MovieClip(downState).txtTitre.text=_titre;
			MovieClip(overState).txtTitre.text=_titre;
		}
		public function get titre():String {
			return _titre;
		}
	}
}

Pour résumer

Et ben voilà C'est pas plus, on a vu que la classe liée se construit exactement selon les mêmes principes que la classe de base, donc rien de plus à mémoriser (chic !)

Quant à la classe SimpleButton, l'important à en connaitre c'est l'histoire des états qui se doivent d'être une instance de clip.

N'allez pas vous emmêler : On est bien d'accord qu'une classe qui étend SimpleButton peut être indifféremment une classe de base ou une classe liée, je ne l'ai utilisée dans ce contexte que dans l'idée de nous gagner un peu de temps (et d'avoir quelque chose à illustrer )

sources CS3

Vers les composants perso

Du coup on s'offre un détour par le composant.
Pour construire un composant il faut impérativement que la classe associée au symbole destiné à devenir composant le soit via le champ Classe, une classe liée donc.

Même si ça a à voire avec ce tuto, du point de vue de la classe liée, vous pouvez sauter la partie composant et continuer par le chapitre suivant : classe de document. Le module composant n'est qu'un détour où rien de nouveau sur les classes ne sera vu.

Itinéraire direct —> Classe de document
Itinéraire découverte —> lien composant (à écrire)

Héritage et surcharge (#1)

Nataly — Mon, 26 Jul 2010 17:28:26 +0200

Introduction
Classe de base (#1)
Classe de base (#2)
Héritage et surcharge (#1)
Héritage et surcharge (#2)
Diffuser des événements
Classe liée
Classe de document
Classe externe : une visionneuse (#1)
Classe externe : une visionneuse (#2)
Classe externe : méthodes statiques

Héritage et surcharge (#1)

Pour illustrer les points qui vont suivre, je vous propose d'écrire quelques classes destinées à gérer des boites de dialogue modales.
On dit d'une boite de dialogue (et d'une fenêtre en général) qu'elle est modale quand sa fermeture est obligatoire pour pouvoir donner le focus à une autre fenêtre. En gros quand on ne peut pas accéder à d'autres éléments d'interface aussi longtemps qu'elle est affichée (ça empêche l'utilisateur de cliquer partout )
Typiquement il s'agit des boites d'alerte et autres boites de type Oui/Non.

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.
Merci Lilive pour l'illustration bien ~~moins laide~~ plus jolie que celle dont je m'étais contentée.

Conception

Comme vous le voyez au dessus, la ruse consiste à créer un écran translucide entre la boite de dialogue et les autres éléments de l'animation.
Le principe de l'écran est commun à toutes les boites, qu'elles soient de type Alerte (un bouton), Question (Oui-Non) ou encore Boite de saisie.

Principe commun, quand on pense classe ça revient à dire héritage. Toutes les boites, si elles sont modales, devront hériter des même caractéristiques, donc d'une même classe qui se chargera d'afficher un écran translucide entre la boite et l'animation.
Appelons cette classe BoiteModale, elle héritera de MovieClip et chacune des classes (BoiteAlerte, BoiteOuiNon…) héritera de BoiteModale.

Dans un premier temps je vous propose de construire une boite d'alerte modale, ensuite ce sera jeu d'enfant de décliner le principe pour d'autres types de boites.

On est d'accord sur le fait qu'il va nous falloir, outre un fla de mise en œuvre, une classe BoiteAlerte et une classe BoiteModale.
Si on anticipe le fait que plus tard viendront s'ajouter des classes BoiteSaisie, BoiteOuiNon, et d'autres, on ne peut plus se satisfaire de tout ranger dans le même répertoire (le fla et les classes auxquelles il fait appel). D'autant moins que ces classes vont nous être utiles chaque fois que, dans un projet ou un autre, nous auront recours à une boite de type modal.

Organisation du disque et chemin de classe

Le .fla de test

Le .fla de test c'est pure formalité :
Dans sa bibliothèque il faut un clip qui sera une boite d'alerte. Faire aussi moche que sur la demo ne devrait pas vous prendre trop de temps, pour l'instant même un simple rectangle (pour y voir quelque chose) suffirait.

Et on l'enregistre là où ça nous arrange…

Organiser les classes

En revanche pour ce qui est des classes, cette fois on ne va pas les laisser dans le même répertoire que le fla.
Il est de tradition d'avoir dans un coin de disque un répertoire Outils, ou Utils, voire Utilitaires dans lequel on range ses classes perso.
Afin de ne pas risquer de confusions avec des répertoires pré-existants, ce dossier je vais le nommer Mezoutils.
Dedans, un sous-répertoire Interface et dedans encore un autre répertoire BoitesModales, comme ça ce sera bien propre.

A terme donc nous aurons quelque chose qui ressemblera à ça :

On est d'accord que ce clip (Mv_BoiteAlerte, par exemple) est destiné à être associé à la future classe BoiteAlerte qui étendra la future classe BoiteModale. Ces deux classes seront rangées - empaquetées - dans le répertoire Interface/BoiteModale. C'est cette hiérarchie de dossier qui détermine le nom du paquetage, ici : Interface.BoiteModale.
On sait tout, yapuka…

Créons les classes avec seulement un trace dans le constructeur :

package Interface.BoiteModale {
      import flash.display.MovieClip;
 
      public class BoiteModale extends MovieClip {
            public function BoiteModale ():void {
               trace("passage constructeur BoiteModale ");
            }
      }
}

package Interface.BoiteModale {
 
      public class BoiteAlerte extends BoiteModale {
            public function BoiteAlerte():void {
               trace("passage constructeur BoiteAlerte");
            }
      }
}

La seule chose nouvelle c'est le nom du paquetage : pour “atteindre” la classe BoiteAlerte on utilisera donc la syntaxe Interface.BoiteModale.BoiteAlerte, au même titre qu'on utilise par expemple flash.display.MovieClip quand il s'agit de la classe MovieClip.

Il ne reste plus qu'à associer Interface.BoiteModale.BoiteAlerte et le symbole Mv_BoiteAlerte via le champ Classe de base.

Si ce n'est que, par défaut, le compilateur va chercher la classe ou le paquetage dans le même répertoire que le .fla, où il ne le trouve pas, et pour cause on l'a rangé dans le répertoire Mezoutils…

Il faut donc préciser dans les préférences de publication (menu Fichier) le chemin vers ce répertoire Mezoutils :

Et voilà :

Vérifier

Cette fois c'est bon, on va pouvoir avancer.
Pour être certains que le compilateur retrouve ses petits, testons l'histoire d'une simple ligne dans le fla :

var bteAlerte:Mv_BoiteAlerte=new Mv_BoiteAlerte();

passage constructeur BoiteModale 
passage constructeur BoiteAlerte

Je suis bien d'accord, vérifier que ça fonctionne juste en s'extasiant sur quelques lignes dans le panneau de sortie ce n'est toujours pas plus satisfaisant. Temporairement, pour voir ce qu'on fait, on va donc ajouter l'instance de bteAlerte à la liste d'affichage avec un addChild dans le .fla.

Puisque l'objectif est de fabriquer une boite modale qui en s'affichant proscrira l'accès aux autres éléments de l'animation, profitons en pour ajouter sur la scène quelques boutons et un champ de saisie.

var bteAlerte:Mv_BoiteAlerte=new Mv_BoiteAlerte();
addChild(bteAlerte);

Pour l'instant ça ne proscrit rien du tout, c'est le contraire qui aurait été étonnant on n'a rien fait pour

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.

La classe mère

Il s'agit, pour toutes les boites modales, de fabriquer - quoiqu'il arrive - un écran (une forme) aux dimensions de la scène et de l'ajouter. Ça concerne donc la classe BoiteModale dont dériveront (hériteront) toutes les autres, et ça se passe dans le constructeur.
Avant même de se lancer dans les grandes manœuvres, une chose est sûre : pour dessiner un truc aux dimensions de la scène, il faut les avoir, les dimensions. Trop facile ! C'est stage.stageWidth, et stage.stageHeight, clame Ronchon dans un élan de bonne humeur retrouvée.
Bonne humeur qui ne dure pas car justement, si on teste stage.width dans le constructeur on est désappointé : l'éternelle erreur 1009 (Il est impossible d'accéder à la propriété ou à la méthode d'une référence d'objet nul) est renvoyée.

propriétés stage, root, et parent d'une instance

Regardons ça de plus près, c'est qui le nul ?

public function BoiteModale():void {
	trace("passage constructeur BoiteModale "+this);
	trace("scène "+stage)
}

passage constructeur BoiteModale [object Mv_BoiteAlerte]
scène null
passage constructeur BoiteAlerte

Et bien c'est la scène semble-t-il… Comment ça ??
En fait c'est logique, souvenons nous : le constructeur est invoqué à la création de l'instance, avant donc que la-dite instance soit ajoutée. D'ailleurs, le premier test on l'a fait sans même invoquer un addChild. var monObjet:MaClasse = new MaClasse() hop ! ça invoque le constructeur, et à ce moment là l'objet n'étant pas dans liste d'affichage les propriétés, parent, root, et stage renvoient tout naturellement null…
Zutalors, comment faire ?
Tout bêtement en attendant que l'instance soit ajoutée pour utiliser ses propriétés parent, root ou stage. Dès qu'une instance est ajoutée, l'événement ADDED_TO_STAGE est diffusé (l'instance crie “Ayé ! Je suis dans la liste d'affichage”). Pour nous il suffit donc d'écouter cet événement (importez le package flash.events.Event)

	import flash.events.Event;

public function BoiteModale():void {
	trace("passage constructeur BoiteModale "+this);
	this.addEventListener(Event.ADDED_TO_STAGE,QdAjouté);
}
 
private function QdAjouté(e:Event) {
	trace("qd ajouté ");
	trace(stage.stageWidth);
}

passage constructeur BoiteModale [object Mv_BoiteAlerte]
passage constructeur BoiteAlerte
qd ajouté 
500

Notez bien qui est this

Dessiner dans une forme

Pour dessiner dans une forme il faut d'abord créer une forme :

var uneForme:Shape=new Shape  ;

… puis utiliser sa propriété graphics qui permet d'avoir recours à un ensemble de méthodes pour dessiner des formes vectorielles. Par exemple pour dessiner un rectangle rouge et opaque (alpha=1) de 300 sur 100 (largeur/hauteur) on écrirait :

// remplissage rouge opaque
uneForme.graphics.beginFill(0xFF0000,1);
// dessiner un rectangle en 0/0 300 large, 100 haut
uneForme.graphics.drawRect(0,0,300,100);

Appliqué à ce qui nous préoccupe ça donne :

• Créer (et ajouter) une forme dans le constructeur, une bonne fois pour toutes.
• Dessiner dans la forme une fois l'instance ajoutée à la liste d'affichage pour avoir accès aux dimensions de scène.

Puisque la forme destinée à faire écran sera crée dans une fonction et utilisée (pour y dessiner) dans une autre, il nous faut ne variable globale privée, nommons la _ecran.

	public class BoiteModale extends MovieClip {
		private var _ecran:Shape;
 
         [...]

		public function BoiteModale():void {
                        // a l'initialisation, créer la forme
			_ecran=new Shape();
                        // ajouter _ecran à liste d'affichage (tout en bas)
			addChildAt(_ecran,0);
                        // attendre que this soit ajouté sur la scène 
                        // pour avoir accès à ses dimensions  
			this.addEventListener(Event.ADDED_TO_STAGE,qdAjouté);
		}

On a bien pris soin d'utiliser addChildAt avec une profondeur 0, un addChild (tout court) aurait placé la forme au dessus de tout le reste, et proscrit aussi l'accès aux boutons de la boite…

private function QdAjouté(e:Event) {
	trace("qd ajouté ");
	trace(stage.stageWidth);
        // gris en alpha 0.1
	ecran.graphics.beginFill(0x333333,0.1);
	ecran.graphics.drawRect(0,0,stage.stageWidth,stage.stageHeight);			
}

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.

Initialiser et modifier les caractéristiques de l'écran

Au point où on en est, autant permettre à l'utilisateur de définir la couleur et l'opacité (l'alpha) de l'écran. Il suffit de sortir deux variables.

Soit on les déclare publiques et globales, et hop le tour est joué ; soit on décide d'utiliser des accesseurs…

C'est le cas de conscience typique.
Définir des accesseurs qui ne feront rien d'autres que modifier la valeur d'une variable globale (certes privée)…
Mouais…
Arguer que oui mais ça permettrait de modifier la couleur de l'écran après l'affichage…
Je réponds à nouveau d'un borborygme pas convaincu. Ça n'a pas grand sens, ce sont des boites destinées à être affichées pour prévenir de toute autre action utilisateur que celle qu'on attend… Quand va-t-on avoir besoin de modifier la couleur ou l'alpha, ou ce qu'on voudra, après l'affichage de la dite boite, pendant que l'utilisateur n'a d'autre recours que cliquer sur le bouton OK ?
En plus, pour ceux qui s'y essaieront quand même (si, si, c'est de bonne guerre), il y aura des surprises, pas incontournables, mais des surprises. Alors écrire une usine pour offrir une fonctionnalité inutile, sur ce coup là, c'est sans moi

Donc deux globales publiques !

	public class BoiteModale extends MovieClip {
 
		public var coulEcran:uint=0x333333;
		public var alphaEcran:Number=0.1;
 
		private var _ecran:Shape;
 
                [...]

		private function qdAjouté(e:Event) {
			_ecran.graphics.beginFill(coulEcran,alphaEcran);
			_ecran.graphics.drawRect(0,0,stage.stageWidth,stage.stageHeight);
		}

Appel depuis le fla :

var bteAlerte:Mv_BoiteAlerte=new Mv_BoiteAlerte();
bteAlerte.coulEcran=0xFF0000;
bteAlerte.alphaEcran=0.5
addChild(bteAlerte);

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.

Déterminer les coordonnées de la boite

Cette fois ça suffit, notre boite de dialogue toute coincée là haut, ça ne peut plus durer.
Il faut pouvoir disposer la boite de dialogue là où on veut sur la scène à l'aide des propriétés x et y :

bteAlerte.y=50;

Si ce n'est qu'en l'état ça descend tout en 50. La boite et l'écran.

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.

Normal.
L'écran est ajouté à l'instance - via la classe mère - il est déplacé avec elle

reprenons le processus :
1) on crée une instance (new Mv_Alerte())
2) on invoque affiche –> passage dans qdAjouté –> dessin d'un rectangle dans de _ecran en 0/0 :

_ecran.graphics.drawRect(0,0,stage.stageWidth,stage.stageHeight);

Dans le cas qui nous occupe il faudrait qu'il soit créé en 0/-50, pour compenser le décalage vertical. - 50, c'est -y… Pour x c'est même combat… Modifions donc :

		private function qdAjouté(e:Event) {
			_ecran.graphics.clear();
			_ecran.graphics.beginFill(coulEcran,alphaEcran);
                        // répercuter le décalage x/y
			_ecran.graphics.drawRect(-x,-y,stage.stageWidth,stage.stageHeight);
		}

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.

C'est un bon début. Maintenant on va faire en sorte que la boite s'auto-affiche : on veut pouvoir l'utiliser comme suit :

var bteAlerte:Mv_BoiteAlerte=new Mv_BoiteAlerte();
bteAlerte.affiche();

… ou presque… Bon d'accord on va rencontrer deux trois subtilités… Et, je sais pas vous, mais moi je ferais bien une pause, alors on se retrouve là tout de suite après ?

Héritages et surcharge (#2)

Nataly — Mon, 26 Jul 2010 17:27:55 +0200

Introduction
Classe de base (#1)
Classe de base (#2)
Héritage et surcharge (#1)
Héritage et surcharge (#2)
Diffuser des événements
Classe liée
Classe de document
Classe externe : une visionneuse (#1)
Classe externe : une visionneuse (#2)
Classe externe : méthodes statiques

Héritages et surcharge (#2)

Allez ! J'espère que vous êtes tout frais pétillants : on va aborder les choses sérieuses. Pas de panique, j'ai pas dit difficiles, juste qui nécessitent un zeste de concentration, mais comme on revient de pause, tout va bien

L'objectif c'est de pouvoir utiliser toute boite héritant de BoiteModale de façon “autonome”. Comprendre qu'elles exposent toutes une méthode affiche et… non, pas de méthode fermer puisque la fermeture est toujours conséquence d'un clic sur l'un des boutons de la boite. Quand je dis pas de méthode fermer, j'entends pas de méthode exposée, il faudra bien qu'à un moment ou à un autre on en programme la fermeture

Méthode ''affiche''

Dans nos rêves on veut donc utiliser comme suit :

// on crée l'objet une bonne fois pour toutes
var bteAlerte:Mv_BoiteAlerte=new Mv_BoiteAlerte();
 
// on l'affiche autant de fois que nécessaire
btT1.addEventListener(MouseEvent.CLICK,test);
function test(me:MouseEvent) {
	bteAlerte.affiche();
}

La boite se fermera automatiquement quand l'utilisateur cliquera sur le bouton (seul et unique en cas de boite d'alerte, mais même chose pour les boites avec plusieurs boutons).

Cette méthode affiche (tant pis je me répète) sera commune à toutes les boites de dialogue, par conséquent elle concerne la classe mère BoiteModale.

Zou ! Direction la classe, on écrit une fonction publique (puisque exposée) qui contient une ligne utilisant addChild pour ajouter à la liste d'affichage.
Ajouter qui ? Et bien this puisque (vous l'avez tracé) c'est Mv_BoiteAlerte, dans notre exemple.

On écrirait bien un truc du genre root.addChild(this), mais… on n'a pas encore accès à la propriété root, on l'aura quand ce sera affiché… Le serpent se mord la queue

Pas d'autres solution¹⁾ qu'avoir préalablement valorisé une variable racine. On va donc le faire (ce sera une contrainte d'utilisation) avant l'appel à la méthode affiche, depuis le .fla, ce qui donnera :

// le .fla
var bteAlerte:Mv_BoiteAlerte=new Mv_BoiteAlerte();
bteAlerte.racine=root;
 
btT1.addEventListener(MouseEvent.CLICK,test);
function test(me:MouseEvent) {
	bteAlerte.affiche();
}

Dans la classe on déclare une variable publique racine de type DisplayObject, et on pense à importer le paquetage flash.display.DisplayObject.

// classe BoiteModale
package Interface.BoitesModales{
	import flash.display.MovieClip;
	import flash.display.Shape;
	import flash.display.DisplayObject;
	import flash.events.Event;
 
	public class BoiteModale extends MovieClip {
 
		public var racine:DisplayObject;
 
        // … suite

Et on écrit la bête fonction affiche, qui doit être publique (on l'appelle de l'extérieur).

		public function affiche():void {
			trace("méthode affiche ds modale");
			MovieClip(racine).addChild(this);
		}

Pour se prévenir de toute mauvaise surprise, quand plus tard on aura (peut-être) oublié que la propriété racine doit impérativement être valorisée, et afin d'éviter un message d'erreur abscons :

		public function affiche():void {
			trace("affiche modale");
			if (racine==null) {
				trace("ATTENTION la propriété racine doit être valorisée (root)");
				return;
			}
			MovieClip(racine).addChild(this);
		}

C'est bien joli, mais on ne peut plus s'en débarrasser.
Il nous faut une fonction ferme qui sera invoquée depuis le bouton OK de la boite d'alerte.

Méthode ''ferme''

Toutes les boites disposeront de cette fonction, c'est une caractéristique commune, c'est donc la classe mère qui est concernée.

		internal function ferme():void {
			trace("ferme Mère ");
			MovieClip(racine).removeChild(this);
		}

Heuhhh ! Qu'est ce que c'est que ce internal ???
Jusqu'alors en s'en était sorti avec les mots clé attribut (c'est comme ça que ça s'appelle ) private ou public. D'un certain point de vue cette fonction n'est pas publique puisqu'on ne l'appellera pas depuis le .fla, mais si on la déclare privée, on ne pourra pas l'invoquer depuis la classe fille… Et bien, voilà, dans ce cas on utilise internal qui rend la fonction (la variable ou la classe considérée) disponible pour tous les appels au sein du même paquetage.

Ne reste plus qu'à l'appeler dans BoiteAlerte au clic sur bouton. C'est le moment d'ajouter le bouton en question, si ce n'est déjà fait.

 
// ******** requiert ******************
//btOK :bouton
//*************************************
 
 
package Interface.BoitesModales{
	import flash.events.MouseEvent;
 
	public class BoiteAlerte extends BoiteModale {
 
		public function BoiteAlerte():void {
			trace("passage constructeur BoiteAlerte");
			btOK.addEventListener(MouseEvent.CLICK,btOKQdClick);
		}
		private function btOKQdClick(me:MouseEvent):void {
			trace("ferme ");
			ferme();
		}
	}
}

Oui : c'est pas plus mal de prendre l'habitude, quand vous écrivez des classes de base, de préciser en commentaire les objets requis dans le symbole associé. Vous en serez bien contents un jour ou l'autre

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.

Youpi ! On assure grave !

Raa… Non ! Pas encore tout à fait : si on appelle la boite plusieurs fois de suite, à chaque appel l'écran est un peu plus opaque… Normal, à chaque fois qdAjouté est invoquée et un rectangle supplémentaire est dessiné dans la forme _ecran. Les rectangles se superposant l'opacité l'est chaque fois plus - opaque
Ça c'est rien du tout, peut être même avez vous anticipé d'une ligne qui efface juste avant de dessiner :

		private function qdAjouté(e:Event) {
                        // effacer
			_ecran.graphics.clear();
			_ecran.graphics.beginFill(coulEcran,alphaEcran);
			_ecran.graphics.drawRect(0,0,stage.stageWidth,stage.stageHeight);
		}

Surcharge

Surcharger la méthode affiche de BoiteModale

Occupons nous maintenant d'afficher un texte de notre choix dans la boite d'alerte.

On souhaite pouvoir initialiser le champ texte avant d'afficher la boite de cette façon :

function test(me:MouseEvent) {
 
	if (txtSaisie.text=="") {
		bteAlerte.prompt="le champ ne doit pas être vide";
	} else {
		bteAlerte.prompt="saisie : "+txtSaisie.text;
	}
	bteAlerte.affiche();
}

Déclarer une variable globale publique prompt dans la classe BoiteAlerte ce n'est pas le plus difficile, en revanche comment se sortir de cette méthode affiche que l'on a définie dans la classe BoiteModale ? C'est une méthode commune, elle doit rester dans la classe mère.
On veut qu'elle s'enrichisse d'une fonctionnalité supplémentaire pour les boites d'alerte : la méthode doit, pour tout le monde, ajouter le clip à la racine, et en plus, pour les boites d'alerte, écrire dans le champ texte. On va donc re-écrire la fonction affiche dans la classe fille en la surchargeant. Les anglophones pensent “prendre le dessus” et écrivent override.

Pour surcharger une méthode (ou une propriété),
il faut respecter la même signature et faire précéder du mot clé override.

Ça donne ça :

// Classe BoiteAlerte
	public class BoiteAlerte extends BoiteModale {
		public var prompt:String="";
 
// [...]
 
		override public function affiche():void {
			trace("alerte affiche");
                        // écrire dans le champ texte
			txtPrompt.text=prompt;
                        // invoquer la méthode de la classe mère
			super.affiche();
		}

Comme vous le constatez, pour exécuter une méthode surchargée on utilise le mot clé super.

Surcharger les propriété ou des méthodes natives

Là, je suis désolée : impossible de phosphorer une illustration du principe de la surcharge des fonctions natives d'une classe, appliquée à cet exemple, qui ne soit pas complètement capilotractée… J'en appelle donc à votre grande mansuétude pour ce qui va suivre…

Ce qu'il faut savoir c'est que le principe de surcharge n'est pas réservé aux fonctions écrites par nous même dans nos propres classes. On peut surcharger n'importe quelle méthode ou propriété d'une classe native, pour peu qu'on en ait la signature. Imaginons que nous souhaitions interdire à l'utilisateur de boites modale l'utilisation de la propriété alpha parce que… parce que… parce qu'il me faut bien exemple…

Consultons la doc à propos de la propriété alpha.
Regardez l'entrée implémentation :

Implémentation

  public function get alpha():Number
  public function set alpha(value:Number):void

Extrait de la documentation

Oh ! Un couple d'accesseurs
Parfait, ce sont des fonctions, on peut donc surcharger le setter d'une petite ligne à nous (comme on l'a fait avec notre fonction affiche à l'instant).

		override public function set alpha(pA:Number):void {
			trace("Utilisation de l'alpha proscrite");
		}

En vrai elle ne fait rien cette fonction, mais rien de rien si on considère qu'une ligne de trace c'est rien. Elle n'appelle même pas la super classe. C'est ce qu'on veut… Pas d'appel, pas de modification de l'alpha.
Si on avait voulu l'invoquer tout de même cette propriété alpha de la classe mère (super-classe) on aurait écrit super.alpha=….
A noter :
Pour aller vite j'ai dit, à l'instant, qu'on pouvait surcharger les propriétés des classes natives, pour peu qu'elles soient définies par des accesseurs, bien sûr.

Résultat des courses

Et voilà ce que vous pourrez obtenir :

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.

Appel dans le .fla :

// le .fla
var bteAlerte:Mv_BoiteAlerte=new Mv_BoiteAlerte();
bteAlerte.racine=root;
bteAlerte.y=50;
bteAlerte.x=100;
bteAlerte.alpha=0
 
btT1.addEventListener(MouseEvent.CLICK,test);
function test(me:MouseEvent) {
	bteAlerte.alphaEcran=0.1;
	if (txtSaisie.text=="") {
		bteAlerte.coulEcran=0xFF0000;
		bteAlerte.prompt="le champ ne doit pas être vide";
	} else {
		bteAlerte.coulEcran=0x00FF00;
		bteAlerte.prompt="saisie : "+txtSaisie.text;
	}
	bteAlerte.affiche();
}

La classe BoiteModale :

// BoitesModales.as
 
package Interface.BoitesModales{
	import flash.display.MovieClip;
	import flash.display.Shape;
	import flash.display.DisplayObject;
	import flash.events.Event;
 
	public class BoiteModale extends MovieClip {
 
		public var racine:DisplayObject;
		public var coulEcran:uint=0x333333;
		public var alphaEcran:Number=0.1;
 
		//
		private var _ecran:Shape;
		private var _largeur:Number;
		private var _hauteur:Number;
 
		public function BoiteModale():void {
			//trace("passage constructeur BoiteModale ");
                        // lire hauteur et largeur de la boite AVANT dessin de l'écran
			_largeur=width;
			_hauteur=height;
			_ecran=new Shape();
			addChildAt(_ecran,0);
			this.addEventListener(Event.ADDED_TO_STAGE,qdAjouté);
		}
		//-------------------------------------------------
		private function qdAjouté(e:Event) {
			_ecran.graphics.clear();
			_ecran.graphics.beginFill(coulEcran,alphaEcran);
			_ecran.graphics.drawRect(-x,-y,stage.stageWidth,stage.stageHeight);
		}
 
 
		public function affiche():void {
			trace("affiche modale");
			if (racine==null) {
				trace("ATTENTION la propriété racine doit être valorisée (root)");
				return;
			}
			MovieClip(racine).addChild(this);
		}
		internal function ferme():void {
			//trace("ferme Mère ");
			MovieClip(racine).removeChild(this);
		}
 
               // on en aura bien besoin un jour ;)
		public function get largeurBoite():Number {
			return _largeur;
		}
		public function get hauteurBoite():Number {
			return _hauteur;
		}
 
		// Surcharge alpha
		override public function set alpha(pA:Number):void {
			trace("Utilisation de l'alpha proscrite");
		}
	}
}

Classe BoiteAlerte :

// BoiteAlerte.AS
 
// ******** requiert ******************
//btOK : bouton
//txtPrompt : TextField 
//*************************************
 
 
 
package Interface.BoitesModales{
 
	import flash.events.MouseEvent;
 
	public class BoiteAlerte extends BoiteModale {
		public var prompt:String="";
 
		public function BoiteAlerte():void {
			trace("passage constructeur BoiteAlerte");
			btOK.addEventListener(MouseEvent.CLICK,btOKQdClick);
		}
		private function btOKQdClick(me:MouseEvent):void {
			trace("ferme ");
			ferme();
		}
		override public function affiche():void {
			trace("alerte affiche");
			txtPrompt.text=prompt;
			super.affiche();
		}
	}
}

Pour résumer

Récapitulons nous :

Le concept de surcharge (override en anglais) intervient lorsqu'on a besoin de modifier certaines fonctionnalités héritées. (Ça c'est T.Imbert qui le dit, je vois pas l'intérêt de formuler plus mal sous couvert de dire autrement )

Pour surcharger une fonction héritée on utilise le mot clé override et on respecte la signature.
On trouve la signature des méthodes natives dans la documentation sous l'entrée implémentation.
On invoque la fonction de la classe mère à l'aide de l'instruction super.

Vocabulaire

Ici sans le savoir, nous avons mis en place les techniques d'encapsulation et de polymorphisme.

Encapsuler c'est “cacher” ou proscrire l'accès direct à certaines méthodes ou propriétés d'une classe. A chaque fois qu'on utilise des accesseurs pour modifier une propriété (plutôt qu'en faire une simple variable publique) on encapsule. A chaque fois qu'on définit une méthode comme privée ou interne (internal) on l'encapsule aussi (ici la méthode ferme, par exemple).

Le polymorphisme c'est le fait de définir des comportements différents pour une même méthode, selon la classe dont elle dépend au sein d'un même arbre d'héritage. La doc l'explique comme suit :

Par exemple, vous pouvez commencer par une classe appelée Mamifere qui comporte les méthodes play() et sleep(). Vous créez ensuite les sous-classes Chat, Singe et Chien pour étendre la classe Mamifere. Les sous-classes supplantent la méthode play() de la classe Mamifere, de façon à représenter de façon plus réaliste ces types d'animaux. La classe Singe implémente la méthode play() pour se balancer aux arbres ; la classe Chat implémente la méthode play() pour courir après une pelote ; la classe Chien implémente la méthode play() pour rapporter une balle. Dans la mesure où la fonctionnalité sleep() reste similaire quelque soit l'animal, vous utiliseriez l'implémentation de super-classe.

Extrait de la documentation

La super-classe c'est la classe mère.

En gros le simple fait de surcharger une méthode ou une propriété c'est du polymorphisme, donc en surchargeant affiche nous avons fait du polymorphisme, tous seuls comme des grands, plus fort que Jourdain !

Cliquez pour continuer

Le titre c'est surtout pour marquer la transition, séparer ce paragraphe du résumé qui précède et introduire la suite.
Parce que suite il y a.
On pourrait croire en être quitte pour ce qui est de la boite d'alerte, mais il manque encore quelque chose…
Imaginez que vous utilisiez ce type de boite d'alerte après avoir mis en en pause une animation, quand l'utilisateur clique, l'animation reprend… Et comment le sait-on que l'utilisateur a cliqué ?

Diffuser des événements -->

¹⁾ Si il y a d'autres solutions, par exemple passer la variable en argument. j'ai fait le choix qui m'arrangeait, vous ferez le votre…

Classe de base (#2)

Nataly — Mon, 26 Jul 2010 17:24:44 +0200

Introduction
Classe de base (#1)
Classe de base (#2)
Héritage et surcharge (#1)
Héritage et surcharge (#2)
Diffuser des événements
Classe liée
Classe de document
Classe externe : une visionneuse (#1)
Classe externe : une visionneuse (#2)
Classe externe : méthodes statiques

Classe de base (#2)

Variables d'instances

Vous avez donc un code qui ressemble à ça

package {
 
	import flash.display.MovieClip;
	import flash.filters.BitmapFilterQuality;
	import flash.filters.BlurFilter;
 
	public class AvecFlou extends MovieClip {
		public function AvecFlou():void {
			masque.filters=[new BlurFilter(10,10,BitmapFilterQuality.HIGH)];
			photo.mask=masque;
			photo.cacheAsBitmap=true;
		}
	}
}

On remarque que les instances de clip nommées masque et photo sont “directement utilisables”. La classe connait leur nom semble-t-il.
C'est l'effet d'un réglage par défaut des préférences fichier de Flash.

Quand la case Déclarer automatiquement les occurrences est cochée, le compilateur déclare, tout seul dans son coin, des variables pour les instances de symboles posées sur les calques. Ces variables ont le bon goût d'avoir le nom des instances auxquelles elles renvoient.

Décochez la case de la scène, enregistrez, testez.

1120: Accès à la propriété non définie masque.
1120: Accès à la propriété non définie photo.

Je ne commente pas, c'est assez parlant…
Si ?
En langage compilateur ça veut dire : “Hey gars ! Tu utilises le mot photo que je ne trouve nulle part. J'en déduis que c'est une propriété et que tu ne l'as pas déclarée (définie)”.

A nous donc de déclarer les variables auxquelles nous ferons référence.

	public class AvecFlou extends MovieClip {
		public var masque:MovieClip
		public var photo:MovieClip
 
		public function AvecFlou():void {
			//… suite …

Et tout rentre dans l'ordre
Je vous le signale, non pas pour que vous travailliez dans ce mode (à vous de voir) mais surtout pour que si un jour la bestiole se mettait à vous crier des insultes de ce genre, vous puissiez aller vérifier si un malintentionné quelconque n'aurait pas décoché cette fichue case à votre insu (pas vous par inadvertance, non, ça jamais…)
Et puis aussi pour répondre aux légitimes interrogations du type : mais d'où ça sort ? Pourquoi dispos-je de variables que je n'ai pas déclarées (j'en connais qui pinaillent )

Les deux variables masque et photo doivent être accessibles (visibles) partout dans la classe, c'est pourquoi elles sont déclarées dans la classe elle même (on dit qu'elles sont globales).

Les propriétés

Tout irait pour le mieux dans le meilleur des mondes si Ronchon ne s'avisait que c'est quand même dommage que le flou soit toujours de 10. Si il veut 15 ou 70 il faut écrire deux autres classes ? Il ne va pas en fabriquer une par valeur quand même ?! Il lui faudrait une propriété… Il faudrait qu'il puisse écrire dans le fla quelque chose du genre :

clipDemo.flou=25;

Et bien ! Il n'a qu'à écrire une méthode appliqueFlou à qui il passera une valeur pour le flou en x, une autre pour le flou en y, répondez vous immédiatement, maintenant que vous savez faire.

// le fla
 
function test(me:MouseEvent) {
	clipDemo.appliqueFlou(25,25)
}

// .as
 
public function appliqueFlou(pFlouX:int,pFlouY:int):void {
	masque.filters=[new BlurFilter(pFlouX,pFlouY,BitmapFilterQuality.HIGH)];
}

Mmmoui… mais non, argumente-t-il. Pour lui c'est plus une propriété, ça caractérise son clip. C'est quand même dommage qu'on ne puisse pas écrire :

function marche(me:MouseEvent) {
	Demo1.flouX=25;
	Demo1.flouY=5;
}

Qui a dit qu'on ne pouvait pas ? On ne sait pas, nuance.
Et bien découvrons

Accesseurs (setter/getter)

On le sait, on dit d'une propriété qu'elle est en lecture quand on peut l'interroger, en écriture quand on peut la valoriser. Le plus souvent elles sont en lecture/écriture (on dit aussi lecture/définition).
Au point où on en est, on va fabriquer deux propriétés (flouX et flouY) en lecture/écriture.
Ça s'obtient à l'aide de fonctions dites fonctions d'accesseur (du verbe accéder) qui ont la particularité d'utiliser le mot get ou set selon qu'elle seront utilisées en lecture (get) ou en écriture (set).
Vous rencontrerez souvent l'anglissisme getter/setter.
Ces méthodes bizarres (on les appelle méthodes accesseur) requièrent un nombre précis* de paramètres et sont utilisées comme de bêtes propriétés : DemoFlou.flouX=75; ou var valeurFlouX:Number= DemoFlou.flouX;

* un et un seul paramètre pour set
aucun paramètres pour pour get

Pour écrire (définir) :

public function set flouX(pFlouX:Number):void {
	masque.filters=[new BlurFilter(pFlouX,10,BitmapFilterQuality.HIGH)];
}

Pour lire, on fait la même ou chose ou presque, la même fonction accesseur (même nom) mais cette fois utilisant le mot get et en renvoyant du Number (puisque c'est le type requis avec BlurFilter).

public function get flouX():Number {
	return ??????
}

Ah mais oui… retourne quoi ? Où l'a-t-on la dernière valeur appliquée au flou x ?
Nulle part

Pas grave, on le fait. Dans le setter flouX (function set flouX) il faut non seulement appliquer le flou, mais aussi mémoriser la valeur pour pouvoir la récupérer, plus tard, à la lecture. Pour mémoriser une valeur on utilise une variable. Elle doit être visible partout, on la déclare donc en globale (dans le bloc de la classe) et privée parce que ça ne regarde que nous, c'est de la cuisine interne.

private var _flouX:Number=10;

Voilà pour la propriété flouX de Ronchon, je vous laisse faire le flouY ?

	public class AvecFlou extends MovieClip {
		public var masque:MovieClip;
		public var photo:MovieClip;
		private var _flouX:Number=10;
 
		public function AvecFlou():void {
			masque.filters=[new BlurFilter(_flouX,10,BitmapFilterQuality.HIGH)];
			photo.mask=masque;
			photo.cacheAsBitmap=true;
		}
		// Accesseurs flouX
		public function set flouX(pFlouX:Number):void {
			_flouX=pFlouX;
			masque.filters=[new BlurFilter(pFlouX,10,BitmapFilterQuality.HIGH)];
		}
		public function get flouX():Number {
			return _flouX;
		}

variable publique

Une autre technique pour écrire une propriété de classe c'est de déclarer une variable globale et publique (afin qu'elle soit accessible de l'extérieur de la classe - c'est le propre d'une propriété -)

L'avantage c'est que c'est vite fait.
Les inconvénients sont au nombre de deux :
• On ne peut les restreindre à la seule lecture
• On ne peut rien en faire en même temps. Je m'explique : dans le cas qui nous occupe on aurait été contents avec une bête variable déclarée au niveau de la classe, genre :

	public class AvecFlou extends MovieClip {
		public var masque:MovieClip;
		public var photo:MovieClip;
 
		private var flouX:Number=10;
        //[… suite ]

Et alors ? Certes elle est accessible et valorisable de l'extérieur : DemoFlou.flouX=75;, mais ça ne change pas le filtre… Dans le même cadre on ne peut pas non plus avec une simple variable limiter les valeurs acceptées ou les modifier.
Par exemple, un accesseur comme celui-ci, permettrait de limiter une propriété vitesse à 100…

public function set vitesse(pVitesse:int):void {
	_vitesse= pVitesse>100?100,pVitesse
}

Tout bien pesé :
il est toujours préférable
d'avoir recours aux accesseurs.

Synthèse : Classe de base

package {
 
	//les imports
	import flash.display.MovieClip;
 
	public class NomClasse extends MovieClip {
                // variables d'instances, quand la case déclarer les occurrences est cochée
		//public var nomInstance:Type;
 
		// variables globales privées ou publiques
		private var _unePrivee:Type //valorisée ou non;
		public var unePublique:Type //valorisée ou non;
 
		// variables d'accesseur
                private var _uneProp:Type=…
 
                //-------------------------------------------------------------
                // constructeur
		public function NomClasse():void {
			// traitements
		}
 
                //-------------------------------------------------------------
                // méthodes
		public function uneMethode():Type {
			// traitements
		}
 
                //-------------------------------------------------------------
                // propriétés accesseur  
		public function set uneProp(pUneProp:Type):void {
			_uneProp=…;
			//traitements
		}
		public function get uneProp():Type {
			return _uneProp;
		}
 
	}
}

A noter
Puisqu'il s'agit d'associer cette classe à un symbole de bibliothèque de type MovieClip, tout naturellement le modèle proposé ci-dessus étend la classe MovieClip.
Sachez que si, et seulement si, le clip associé ne contient qu'une image vous pouvez vous contenter d'étendre la classe Sprite. En effet Sprite est mère de MovieClip, les méthodes et propriétés spécifiques à MovieClip ont toutes à voire avec le scénario et la gestion de la tête de lecture. En l'absence de scénario, la classe Sprite peut “suffire”. Méfiez vous cependant, vous ne pourrez pas non plus ajouter du code sur les images du clip. Essayez un simple trace(“un truc”); vous constaterez l'erreur suivante : 1180: Appel à une méthode qui ne semble pas définie, addFrameScript. (Nous reviendrons sur cette méthode au chapitre classe classique [lien qui va venir])
Sauf excellente raison, privilégiez donc la classe MovieClip.

Mise en œuvre

A titre de mise en œuvre et afin d'illustrer l'intérêt de la classe de base je vous propose de réfléchir à ça :

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.

Imaginez que vous ayez ce type de chose à réaliser.
La partie graphiste de votre personnalité veut ne pas avoir à se préoccuper de quoi que ce soit d'autre que de fabriquer des clips aux visuels divers et variés pour figurer le mobilier, d'en organiser joliment une ou plusieurs instances sur la scène, quitte à les déformer (le lit, par exemple, est réduit dans l'inventaire).

C'est alors que la partie programmeur vient à la rescousse en se disant que somme toute, tous les symboles “mobilier” se comportent de la même façon…
Tous ces clips admettent le glissé/lâché, pivotent sur clic, reprennent position, orientation et échelle originales quand ils sont lâchés hors du plan…

C'est le contexte typique pour écrire une classe qui décrira ces comportements communs à chaque objet. Une seule classe pour plusieurs symboles, ce sera donc une classe de base.

Comment la penser ?
Si vous aviez du écrire le code dans le fla. (On dirait qu'on connaissait pas les classes …)
Certainement auriez-vous écrit “dans le symbole”. Vous auriez dédié un calque au code dans le symbole Mv_Fauteuil (par exemple), souscrit deux écouteurs : un sur souris enfoncée pour déclencher un startDrag, un autre sur souris relâchée pour déclencher un stopDrag (plus quelques lignes pour gérer le retour à l'inventaire en cas de position hors plan).

// [A]
// mémoriser les coordonnées et l'échelle d'origine
var xDep:Number=this.x;
var yDep:Number=this.y;
var scaleDep:Number=this.scaleX;
 
var plan:MovieClip=MovieClip(root).plan;
 
// [B]
// Ajouter les écouteurs
this.addEventListener(MouseEvent.MOUSE_DOWN,f_Enfonce);
this.addEventListener(MouseEvent.MOUSE_UP,f_Lache);
this.buttonMode=true
 
// [C]
// les fonctions souscrites
function f_Enfonce(me:MouseEvent) {
	if (me.altKey&&! me.shiftKey) {
		this.rotation+=45;
		return;
	}
	if (me.altKey&&me.shiftKey) {
		this.rotation-=45;
		return;
	}
	this.scaleX=leClip.scaleY=1;
	this.startDrag(true);
}
 
function f_Lache(me:MouseEvent) {
	stopDrag();
 
	if (this.hitTestObject(plan)) {
		// Touche le plan
		if (Plan.mouseX-this.width/2<0 
		|| plan.mouseX+this.width/2>plan.width
		|| plan.mouseY+this.height/2>plan.height
		|| plan.mouseY-this.height/2<0) {
			// déborde du plan : retour ds l'inventaire
			replace();
		}
	} else {
		//  Hors plan :  retour ds l'inventaire
		replace();
	}
}
// Attribue les coordonnées, l'échelle et la rotation d'origine
function replace() {
	this.x=this.xDep;
	this.y=this.yDep;
	this.scaleX=this.scaleY=this.scaleDep;
	this.rotation=0;
}

Avec ou sans this, puisque c'est l'objet par défaut et que ne rien écrire c'est écrire this…

Et bien, (quasi) pareil dans la classe :
Les lignes [A] et [B] qui sont exécutées quoiqu'il arrive pour chaque instance posée sur la scène, doivent donc se retrouver dans le constructeur pour les unes [B] et dans le bloc classes pour les variables [A]
Quant aux fonctions [C] elles sont définies dans le corps de la classe.

Ecrire une classe associée à un symbole c'est la même chose qu'écrire dans le symbole lui même, aux imports près…
L'avantage c'est que c'est bien plus facile/rapide/maintenable de fabriquer une classe que de copier coller des blocs entiers de code d'un symbole sur l'autre…

Ici on considère que les instances seront initialement posées sur la scène ainsi qu'un clip nommé plan. On se compliquera la vie plus tard

package {
	import flash.display.MovieClip;
	import flash.events.MouseEvent;
 
	public class PlanMeubles extends MovieClip {
		//les variables globales [A]
 
 
		public function PlanMeubles() {
			// les écouteurs et le buttonMode [B]
		}
 
                // [C]
		private function f_Enfonce(me:MouseEvent) {
			// ce qui se passe quand on enfonce la souris
		}
 
		private function f_Lache(me:MouseEvent) {
			// ce qui se passe quand on relâche la souris
		}
 
		private function replace() {
			x=xDep;
			y=yDep;
			scaleX=scaleY=scaleDep;
			rotation=0;
		}
 
	}
}

les sources (fla + as)

Voilà pour le principe et le cadre d'utilisation des classes de base. Quand vous aurez fini de jouer avec le plan, et que vous vous sentirez à l'aise avec ces quelques principes fondamentaux, je vous propose de me rejoindre page suivante pour corser un peu les choses.

Héritage et surcharge -->

Classe associée à un symbole de bibliothèque

Nataly — Mon, 26 Jul 2010 17:23:48 +0200

Classe associée à un symbole de bibliothèque

Introduction
Classe de base (#1)
Classe de base (#2)
Héritage et surcharge (#1)
Héritage et surcharge (#2)
Diffuser des événements
Classe liée
Classe de document
Classe externe : une visionneuse (#1)
Classe externe : une visionneuse (#2)
Classe externe : méthodes statiques

Classe de base (#1)

Nous allons commencer notre randonnée découverte avec la classe de base, c'est de mon point de vue la plus utile des deux, même si c'est souvent à tort la classe liée qui est donnée en exemple.
On écrit ce type de classe, je le rappelle, quand on veut étendre (enrichir) les fonctionnalités d'un clip donc lui ajouter des méthodes et/ou des propriétés et/ou des événements.

Fabriquer le clip

Je vous propose, pour nous simplifier la vie dans un premier temps, de dédier un dossier (répertoire) à nos essais et d'y enregistrer un fichier .fla (DemoClasseBase.fla chez moi). Puisqu'on est dans le cadre 'étendre les capacités d'un symbole Clip', fabriquons-en un (un simple rectangle suffira).
Dans l'idée d'associer à ce symbole une future classe, avant de valider, il faut prendre soin de cocher la case exporter pour ActionScript. Si vous avez procédé par conversion d'une forme, appelez la fenêtre propriétés d'un clic droit dans la bibliothèque.

Que se passe-t-il quand on coche la fameuse case ?

D'abord le champ Classe est automatiquement rempli du nom du symbole et le champ Classe de base contient flash.display.MovieClip

Ensuite quand on valide un avertissement surgit (sauf à ce que vous ayez coché depuis longtemps la case Ne plus afficher) :

Une définition sera générée automatiquement dans le fichier swf lors de l'exportation… Diantre !

Une définition de quoi ?
De classe.

Hé oui en cochant cette brave case, une classe se fabrique dans l'arrière boutique de flash sans que nous en sachions trop rien.
Et cette classe (Mv_Truc dans l'exemple) a pour classe de base flash.display.MovieClip. Comprendre : la classe Mv_Truc sait faire tout ce que sait faire un MovieClip (méthodes : stop, play, nextFrame…) dispose de toutes ses caractéristiques (propriétés : currentFrame, enabled…), diffuse les mêmes événements (removed…), et en plus a ses propres bidules ; des formes, des champs texte, des animations et autres clips, graphiques ou boutons, voire même du code. Je dis 'bidules', vous m'en excuserez : sur ce coup là le parler juste ne ferait que semer l'embrouille
Vite dit : notre classe Mv_Truc (avec son malheureux rectangle) c'est une classe MovieClip en mieux, elle sait faire tout ce que sait faire un MovieClip et en plus affiche un rectangle. On dit qu'elle étend (les capacités) de la classe MovieClip. (je me répète ? )
On dit aussi que Mv_Truc hérite de MovieClip ou encore la classe MovieClip est la classe mère de Mv_Truc. Un peu comme ronchon qui a hérité son caractère de sa mère et y a ajouté son propre goût pour l'informatique.

Ce qu'on se propose de faire, c'est fabriquer une classe à nous qui étendra la classe MovieClip et sera elle même étendue par Mv_Truc. Ainsi toutes les instances de Mv_Truc seront elles douées des mêmes capacités/caractéristiques que les MovieClip, plus celles de notre classe, plus celles propres à Mv_Truc.

Fabriquons donc cette classe !

(Tel que nous l'abandonnons -provisoirement- le .fla dispose seulement d'un symbole dans sa bibliothèque et la scène est vide)

Fabriquer la classe

Créer le fichier

Créons un fichier .as dans le même répertoire que le fla (j'y tiens) il portera le nom de la classe (chez moi DemoBase.as).

Et voilà : l'angoisse de la page blanche !

Le code

Bon… Le début c'est toujours pareil, ça ne se comprend pas ça s'apprend c'est comme ça : toute classe doit être déclarée au sein d'un paquetage - pour des question d'organisation mais on y reviendra - un paquetage ça se dit package en anglais alors zou !

package {
 
}

Ça c'est fait.
Ensuite il s'agit d'y déclarer une classe qui s'appelle DemoBase et qui étend la classe MovieClip (je vous ai suffisamment bassinés avec le verbe pour qu'on n'y revienne pas). En anglais/AS ça s'écrit comme ça :

package {
 
	public class DemoBase extends MovieClip {
 
	}
}

Traduit : voici une classe publique (visible et utilisable par tous) qui s'appelle DemoBase qui étend la classe MovieClip.

Attention à bien écrire class (sans majuscule) et non Class

Ce à quoi il va falloir être vigilant à partir de maintenant, c'est à l'import des classes (les autres). Aussi longtemps que l'on écrit dans l'IDE de flash on n'a pas à s'en préoccuper (ou rarement), les classes les plus fréquemment utilisées sont importées par défaut. Quand on écrit image 1 de la scène stop(), on utilise bien une méthode de MovieClip mais on ne se préoccupe pas de demander à flash de nous mettre le gros outil MovieClip à disposition, c'est fait.
Quand on écrit une classe, plus rien d'implicite, il faut se charger de tout.
Qu'à cela ne tienne, importer la classe MovieClip, c'est une pauvre ligne qu'on ajoute dans la foulée avant la déclaration de classe.

package {
	import flash.display.MovieClip;
 
	public class DemoBase extends MovieClip {
 
	}
}

Ayé ! On a une classe
Qui ne fait rien, qui n'a aucune caractéristique propre, et qui est aussi muette qu'un poisson

Ajouter une méthode

On va donc lui ajouter une méthode - qu'on ait quelque chose à tester - disons test, au hasard. Quand nous aurons associé la classe à un clip, nous pourrons appliquer la méthode test à n'importe quelle instance de ce clip, avec la syntaxe qu'on connait par cœur :

// le fla
 
monClip.test();

La méthode test n'est rien d'autre qu'une fonction qui doit être déclarée dans la classe et accessible depuis l'extérieur, donc publique.

package {
	import flash.display.MovieClip;
 
	public class DemoBase extends MovieClip {
 
		public function test():void {
			trace("je passe dans test");
		}
 
	}
}

Et voilà, la classe DemoBase sait faire tout ce que sait faire un objet de classe MovieClip, et en plus sait écrire “je passe dans test” dans la fenêtre de sortie quand on utilise sa méthode test.
Vérifions…

Associer la classe et le symbole

Pour vérifier, il faut associer cette classe DemoBase au symbole qui s'ennuie dans la bibliothèque du .fla.

Ne vous y trompez pas : tout à l'heure on n'a rien associé. On a regardé ce qui se passait quand on coche la case Exporter pour ActionScript et conclu qu'il nous fallait une classe à glisser entre MovieClip dont le clip hérite naturellement et lui même pour l'enrichir des fonctionnalités de la dite classe.

Retour au fla, donc → propriétés du clip → dans le champ classe de base on saisit DemoBase (sans l'extension le compilateur s'en doute).

Notez le crayon à droite, si vous cliquez dessus et que vous avez ôté les moufles (pas de faute de frappe) vous devez être dirigé sur le code as, sinon il crie :

Validez, posez une instance du clip sur la scène, nommez la.
Dans la fenêtre action appliquez la toute fraiche méthode test à l'instance (leClip.test()), exécutez… Parfait.

je passe dans test

Ça ne surprend personne : quand on pose une instance d'un clip quelconque sur la scène et qu'on utilise la méthode play, hop ça marche ! Je veux dire ça lit…
Et bien pareil pour une instance de classe personnelle, on la pose sur la scène, elle dispose d'une méthode supplémentaire -test- qu'on utilise et hop ça marche ! Enfin, ça trace…

Si rien ne se passe c'est probablement que vous avez oublié d'enregistrer le fichier as…

Juste pour jouer, ajoutons un bouton à la scène :

btMarche.addEventListener(MouseEvent.CLICK,jeTeste)
function jeTeste (me:MouseEvent) {
	leClip.test()
}

Une méthode marche

Tout chaud extrait du forum :

Blague à part, j'ai lu pas mal de trucs, mais ça reste toujours très théorique, et les exemples tournent souvent autour d'un bête trace (t'as vu t'as vu ça fait çaaaaa). :?

Ronchon qui se sent moins seul d'un coup émerge de derrière on écran.
Ok…
Je vous propose de transformer la méthode test qui ne sert à rien en méthode marche qui fera avancer le clip d'autant de pixels que passés en paramètre (comme là ↓).

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.

Si vous tracez this et this.name dans la nouvelle méthode marche, vous constatez qu'il s'agit bien d'un clip de type Mv_Truc et qu'il porte le nom que vous lui avez donné :

package {
	import flash.display.MovieClip;
	public class DemoBase extends MovieClip {
		public function marche():void {
			trace(this);
			trace(this.name);
		}
	}
}

[object Mv_Truc]
leClip

… du coup ajouter un paramètre à la méthode marche et modifier la propriété x (ou y ou les deux, zetes grands), vous n'avez besoin de personne…

package {
	import flash.display.MovieClip;
	public class DemoBase extends MovieClip {
		public function marche(pX:int=10):void {
			x+=pX;
		}
	}
}

Comme on est des malins on a défini une valeur par défaut pour le paramètre : pX:int=10. Ça permet d'utiliser la méthode sans argument et sans déclencher d'erreur…

Pas plus, et vous pouvez faire avancer différentes instances à des vitesses différentes :

btMarche.addEventListener(MouseEvent.CLICK,marche)
function marche (me:MouseEvent) {
	leClip.marche(30)
	leClip2.marche()
}

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.

Ne confondez pas

Ah… Les raisons de l'agitation de Ronchon ne sont pas celles que je croyais.
“Je le savais bien que c'était pareil !” triomphe-t-il.
Il l'a vu partout : on aurait pu aussi bien renseigner le champ Classe du panneau de propriétés. Il vient de vérifier : c'est pareil, ça marche aussi !

Effectivement, ça marche aussi, mais ce n'est pas pareil
Pour preuve : suivons l'idée de Ronchon et renseignons le champ Classe du panneau de propriétés comme reproduit ci-dessus. On dispose d'un rectangle qu'on peut instancier autant qu'on veut et chacune des instances peut “marcher”.
Parfait, ça nous plait bien et on veut la même chose non pas seulement pour un rectangle rouge, mais aussi pour une pastille jaune ou un éléphant rose…
On crée un nouveau symbole avec tiens, une pastille jaune, et puis la routine : appeler ses propriétés, cocher la case exporter pour ActionScript, saisir DemoClasse dans le champ Classe… Valider… Et on se fait crier

On l'a vu (ici) : cocher la case Exporter pour ActionScript génère automatiquement une définition dans le fichier swf lors de l'exportation.

Maintenant qu'on sait comment se ~~construit~~ définit une classe, on peut se représenter ce qui se passe dans l'arrière boutique : une classe que nous aurions écrite comme suit a été générée :

package {
	import flash.display.MovieClip;
	public class DemoBase extends MovieClip {
 
	}
}

Mais comme nous en avons nous même défini une, c'est cette dernière qui est prise en considération.

Tant que nous ne l'avions associée qu'au clip Mv_Truc, DemoBase héritait de MovieClip et en plus affichait un rectangle. Si nous recommençons avec un autre clip (Mv_Pastille par exemple) Alors cette même classe devra hériter de MovieClip et en plus afficher un cercle… Ben ?! 'Faut savoir !! Un rectangle ou un cercle ?!

Alors que si nous associons DemoBase à la classe de base, la définition de Mv_Truc est celle-ci :

package {
	import flash.display.MovieClip;
	public class Mv_Truc extends DemoBase {
 
	}
}

Et rien ne nous empêche d'avoir une

public class Mv_Pastille extends DemoBase {...}

C'est ce que nous avions compris depuis le début

function marche(me:MouseEvent) {
	leClip.marche(30);
	leClip2.marche();
	laPastille.marche(20)
}

L"extension Adobe Flash Plugin est nécessaire pour afficher ce contenu.

La fonction constructeur

J'en vois un qui s'impatiente et voudrait bien du concret. On y vient, juste encore un peu de théorie, pour parler de la fonction constructeur et on aura tout ce qu'il faut pour s'y attaquer - au concret.

Le constructeur, donc, c'est une fonction particulière qui est automatiquement invoquée quand on crée une instance de la classe en question.
Elle doit avoir le nom de la classe et être publique.

package {
	import flash.display.MovieClip;
	public class DemoBase extends MovieClip {
		public function DemoBase():void {
			trace("constructeur DemoBase "+ this.name);
		}
 
                // ... suite ...
	}
}

Enregistrez et testez : la fenêtre sortie affiche un trace par clip présent sur la scène. En effet dans l'arrière cuisine de flash, le fait que nous ayons posé un clip sur la scène a été traduit par ce que nous aurions écrit :

var clip:Mv_Truc= new Mv_Truc()
clip.name="leClip"
// clip.x= ...
// etc.
addChild(clip)

A la ligne var clip:Mv_Truc= new Mv_Truc() une instance est crée, le constructeur invoqué.

C'est donc dans la fonction constructeur qu'auront lieu les initialisations et tout ce qui doit se faire quoiqu'il arrive…

Mise en œuvre

Maintenant qu'on a les idées bien claires, et avant d'aller plus loin, voyons ce qu'on peut faire de qui a été vu jusque là.

Imaginons qu'on soit en situation de fabriquer un nombre certain de clips qui auront tous en commun un clip contenant une image (photo) masqué par un autre clip (masque), le masque étant affligé d'un filtre flou. Les images peuvent être animées ou pas et les masques de formes différentes. Ça nous oblige à chaque fois à trois lignes de codes, toujours les mêmes, placées sur la première image du clip en question… ce qui défrise Ronchon, à l'initiative de qui nous sommes là (je tiens à le rappeler, toutes doléances devant lui être directement adressées )
Le comment du pourquoi est détaillé ici

Les trois lignes donc on les connait :

masque.filters=[new BlurFilter(_flouX,_flouY,BitmapFilterQuality.HIGH)];
photo.mask=masque;
photo.cacheAsBitmap=true;

En assumant le fait qu'il existe un clip photo et un clip masque (pour le masque).

Donc tous les clip “sauront” appliquer masque à photo et auront leurs bidules propres (des photos spécifiques entre autres). On est en plein dans le cadre de la classe. Classe de base donc, puisque plusieurs clips différents devront en hériter.
Cette classe ne dispose d'aucune méthode ou propriété (pour l'instant) mais quoi qu'il arrive elle appliquera un filtre au clip masque, et le reste…
Donc ça s'écrit dans le constructeur.

Parfait vous savez tout ce qu'il faut pour vous débrouiller tous seuls, si ce n'est les classes à importer. Pour cette fois je vous les donne :

	import flash.display.MovieClip;
	import flash.filters.BitmapFilterQuality;
	import flash.filters.BlurFilter;

Ensuite vous n'aurez plus qu'à construire autant de clips que vous voudrez, les associer à cette classe et sans plus une ligne de code vous obtiendrez des choses comme ça. En mieux… N'est-ce pas Ronchon ?

[illustr]

Allez ! Je vous laisse faire, ma série télé commence

On se retrouve là pour la suite (et le corrigé).