 |
|
|
| |
| TUTORIEL FLASH |
|
|
|
| Les classes Screen(), Slide() et Form() |
| Elles se cachent derrière le nouveau paradigme de création d'application proposé par Flash MX 2004 Pro : les écrans.
(10/11/2005) |
  |
L'une des nouveautés les moins
mises en avant de Flash MX 2004 Pro est la possibilité de créer
des diaporamas (à la manière de PowerPoint) et des applications
à bases de formulaires (proche des possibilités offertes par
VisualBasic, lire notre
article du 12/07/04). Ces deux aspects de Flash sont
regroupés sous l'appellation d'écrans.
Les écrans sont pourtant une avancée majeure de FMX04Pro, car
ils modifient totalement la manière de concevoir une application
Flash. L'application ne se base plus du tout sur le scénario
(timeline), mais par écran. Le passage d'un écran à l'autre
se fait soit de manière séquentielle dans un diaporama, soit
en fonction des actions de l'utilisateur (et des évènements).
Il s'agit donc d'une formalisation élégante répondant à toutes
ces applications n'utilisant qu'une image-clef, ou plusieurs
bloquées par un gotoAndStop().
Toute la
gestion des transitions d'un écran à l'autre se fait donc par
ActionScript, les actions de la souris ou les touches du clavier,
là où une animation Flash classique laisse le scénario se dérouler.
Ces nouvelles fonctionnalités profitent d'ailleurs pleinement
des capacités Objet d'ActionScript 2.0 : le développeur peut
entièrement les gérer au travers de la classes Screen(),
et de ses classes héritières, Slide()
et Form(). Ce sont ces trois
classes que nous allons étudier ici.
Screen()
Il s'agit de la classe principale de gestion des écrans. Tous
les objets Slide() et Form()
héritent des propriétés et méthodes de cette classe racine.
En particulier, c'est cette classe qui gère les écrans imbriqués,
leur affichage ou fermeture, et les principaux évènements. Elle
est elle-même une extension de la classe Loader(),
ce qui lui permet de charger des fichiers externes de type SWF
ou JPEG.
Screen() propose nombre d'évènements
de type on(), notamment relatifs
à la souris : mouseDown, mouseOver,
mouseOut, mouseUp,
ainsi que les nouveautés mouseDownSomewhere
et mouseUpSomewhere qui repèrent
un clic même en dehors de l'écran, sont définis dans Screen(),
et donc utilisables également pour un objet Slide()
ou Form().
La classe définit également deux autres évènements on()
: allTransitionInDone
et allTransitionOutDone, qui
servent lors de l'utilisation de transitions d'un écran à l'autre
- donc particulièrement utile pour un diaporama.
Les cinq propriétés (currentFocusedScreen,
rootScreen, indexInParent,
parentIsScreen et numChildScreens)
permettent surtout de connaître la hiérarchie des écrans, tandis
que l'unique méthode, GetChildScreen(),
renvoie un tableau par le biais duquel le développeur peut cibler
les enfants d'un écran en cours.
Slide()
Les diaporamas sont donc fortement inspirés du fonctionnement
de PowerPoint, mais profitent des capacités de Flash. Chaque
diapositive du diaporama peut comprendre autant d'éléments graphiques
que nécessaire, et chaque diapositive enfant hérite (par "transparence")
du contenu des diapositives parentes. De fait, seules les diapositives
sans enfants sont prises en compte lors du parcours du diaporama.
Slide() hérite donc des propriétés
et méthodes de Screen(), mais
y ajoute un grand nombre qui sont spécifiques à son fonctionnement
(et ne s'appliquent pas à Form()).
Celles-ci permettent de manipuler les diapositives, d'en tirer
des informations, ou de naviguer au sein du diaporama.
La notion de navigation étant clef dans un diaporama, les possibilités
s'y rapportant sont nombreuses : huit propriétés (currentSlide,
currentChildSlide, currentFocusedSlide,
firstSlide, lastSlide,
nextSlide, previousSlide
ou encore autoKeyNav) et 5 méthodes
(gotoFirstSlide(), gotoLastSlide(),
gotoNextSlide(), gotoPreviousSlide(),
gotoSlide()). Particulièrement,
la propriété autoKeyNav indique
si la navigation au clavier se fait avec les touches par défaut,
ou d'autres définies par le développeur.
Cette redéfinition des touches se fait grâce au gestionnaire
Slide.defaultKeydownHandler
et à la classe Key(), sous la
forme suivante :
on (load) {
this.defaultKeyDownHandler = function(eventObj:Object)
{
switch (eventObj.code) {
case Key.DOWN :
this.currentSlide.gotoNextSlide();
break;
...
Cela autorise le développeur à personnaliser d'autant son diaporama.
Slide.hideChild et Slide.revealChild
sont les évènements servant à gérer l'affichage et la disparition
d'une diapositive.
Form()
Restent les formulaires, qui posent Flash en concurrent direct
du développement RAD de type VisualBasic, voire Delphi. Chaque
formulaire correspond à un état différent de l'application que
l'on créé, et à la manière des diapositives, chaque formulaire
hérite du contenu graphique de ses parents. Au développeur de
préciser quel formulaire afficher selon les actions de l'utilisateur.
Bien qu'en théorie plus compliqué à gérer, Form()
présente moins de méthodes et propriétés que Slide().
La seule méthode est getChildForm(),
qui renvoie la référence au formulaire ciblé. Il reste ensuite
à l'afficher ou la faire disparaître avec la propriété Form.visible.
Le reste des propriétés permettent de s'y retrouver dans l'ensemble
des formulaires : rootForm renvoi
le formulaire racine, parentForm
le parent immédiat du formulaire en cours, numChildForms
le nombre de formulaires enfants, currentFocusForm
celui qui est ciblé à l'instant.
 |
Forum |
|
|
Réagissez
dans les forums
de JDN Développeurs
|
À partir de là, il est possible de faire apparaître et disparaître
du contenu selon les besoins de l'applications, le tout étant
géré par ActionScript et les évènements clavier/souris qui s'appliquent
de la même manière qu'à une animation Flash classique. |
|
|
|
|
|
|
|
| Quand achetez-vous le plus en ligne ? |
|
|
|
|
|
|
|
|
| |
|
