Play, Stop, gotoAndPlay, gotoAndStop, Zeitspur, Bildrate und ActionScript

[hgseib]

(Bei Tutorials darf nicht jeder, wie ich eben festgestellt habe. Dann halt hier)

Play, Stop, gotoAndPlay, gotoAndStop, Zeitspur, Bildrate und ActionScript

Eine Flash-Animation besteht aus mehreren Frames, die vom ersten bis zum letzten Frame angezeigt werden. Über die Bildrate wird die Zeit eingestellt, wie schnell die Frames wechseln. Objekte, die über mehrere Frames hinweg angezeigt werden, befinden sich in einer Zeitspur. Der eigentlich lineare Ablauf der Animation kann mit ActionScript-Befehle beeinflusst werden. Und genau das verstehen viele nicht richtig!

Bitte einmal merken: das "Objekt X" befindet sich in einer Zeitspur von Frame 5 bis Frame 12.

Wenn beim Framewechsel in eine Zeitspur hinein gesprungen wird, dann werden alle grafischen Objekte dieser Zeitspur angezeigt und alle darin enthalten Programme einmal ausgeführt. Beim Verlassen der Zeitspur werden alle Objekte dieser Zeitspur wieder gelöscht.
Alle direkt in die Zeitspur geschriebenen ActionScript-Befehle werden durch einen onLoad-Event ausgeführt - auch wenn das so nicht extra im Script geschrieben steht. Beim Wechsel von z. B. Frame 6 zu Frame 7 wurde die Zeitspur von Objekt X nicht verlassen, folglich werden auch die Zeitspur-Befehle nicht nochmals ausgeführt. Erst muss diese Zeitspur verlassen werden um erneut in sie hinein springen zu können. Es ist gleich, welcher Frame der Zeitspur als erster aufgerufen wird. Es zählt nur "rein oder raus".
Programme, die an einem onEnterFrame-Event gebunden sind beziehen sich nicht auf die Zeitspur, sondern auf den Framewechsel. Wird Objekt X normal durchlaufen, dann finden 7 Framewechsel statt. onEnterFrame würde 7-mal ausgeführt.

Play und Stop haben absolut nichts mit der Ausführung der Programme zu tun! Diese Befehle steuern nur, ob automatisch zum nächsten Frame gesprungen werden soll. Ein Stop-Befehl stoppt kein Programm und er stoppt auch nicht den Framewechsel! Sondern nur: ob zum "nächsten" Frame gesprungen wird. Folglich wird nach einem Stop-Befehl derselbe Frame nochmals aufgerufen. Was wiederum bedeutet: kein Verlassen und kein Neuanfang einer Zeitspur, aber ein neues onEnterFrame.
Dito "gotoAndStop" bedeutet nicht, dass das Programm im Zielframe nicht ausgeführt wird, sondern, das der Animationsablauf in diesem Frame fortgeführt wird und dort bleibt (loop't), bis ein anderer Befehl dies ändert.
Dito ein gotoAndPlay in den aktuellen Frame bedeutet nicht, dass die Zeitspur-Befehle erneut ausgeführt werden. Die Zeitspur wurde hierbei ja nicht verlassen. Aber danach wird jetzt automatisch der nächste Frame angezeigt.

"Kriminell" ist z. B. so etwas:
var hier=_root._currentframe;
_root.gotoAndStop('xxx');
trace(_root._currentframe);
_root.gotoAndStop(hier);
trace(_root._currentframe);
stop();
wenn Label 'xxx' ausserhalb der aktuellen Zeitspur liegt! Der Programmablauf führt aus der Zeitspur heraus und "neu" wieder rein. Da helfen tausend Stop's nichts. Das Zeitspur-Programm wird erneut ausgeführt. Das läuft ewig, da noch nicht einmal das Zeitlimit für einen Script überschritten wird. Sowas kann nur gewaltsam abgebrochen werden.

"Kurios":
trace('Zeitspur');
_root.onEnterFrame = function() {
trace('onEnterFrame');
};
onEnterFrame wird immer aufgerufen.
Ist eine Animation oder ein MovieClip nur ein Frame lang, dann wird das Zeitspur-Programm nur einmal ausgeführt. Ab zwei Frames läuft die Animation offensichtlich über den letzten Frame hinaus, ehe sie wieder beim ersten Frame beginnt. Deshalb werden hierbei die Zeitspur-Programme wiederholt aufgerufen.

Die Gültigkeit auch Lebensdauer eines Objektes ist an seine Zeitspur gebunden. Ausserhalb von Frame 5 bis 12 kann keine Funktion und kein MovieClip oder sonstiges von Objekt X per Programmierung angesprochen werden. Zu dieser Zeit "leben" /existieren diese Objekte nicht.
Auf der Hauptzeitleite ist das noch verständlich. Dieselben Regeln gelten natürlich auch für die Zeitspuren der MovieClips, die ja alle unterschiedlich gesteuert werden können.
Bei hinzugeladenen Objekte ist zu beachten, das sie nicht direkt nach dem Laden-Befehl (loadMovie, loadVars, usw.) zur Verfügung stehen, sondern erst geladen werden müssen. Was besonders über das Internet eine gewisse Zeit dauert. Diese Objekte und die in ihnen enthaltenen Programme stehen nach ihrem onLoad-Event zur Verfügung (asynchrones Verhalten/ Programmieren).

Programme und Variable, die zur gesamten Laufzeit benötigt werden, definiert man in _root, bzw. in _level0 bzw. in _global. Da diese Objekte "ewig" existieren sind auch alle ihnen zugeordneten Objekte immer verfügbar.


Hiermit sind die bekannten Probleme: "wann wird welches Programm ausgeführt und wann ist es ausführbar" beschrieben.

Dein Eifer in allen Ehren, aber einiges kann ich so nicht unwidersprochen stehen lassen:

Eine Flash-Animation besteht aus mehreren Frames

Meine nicht... Ich versuche diesen ganzen Sprung-Schnickschnack und den daraus folgenden Ärger schon dadurch zu umgehen, dass ich 1-Frame-basiert scripte und alles in Funktionsblöcke lege.

Die Framespringerei ist wie die alten BASIC-Programme auf C64 &Co mit unübersichtlichen GOTOs und GOSUBs: schnell zu erlernen, führt aber zu "Spaghetti"-Code und ist schwer zu warten und zu pflegen...

Dito "gotoAndStop" bedeutet nicht, dass das Programm im Zielframe nicht ausgeführt wird, sondern, das der Animationsablauf in diesem Frame fortgeführt wird und dort bleibt (loop't), bis ein anderer Befehl dies ändert.

Entweder hab ich das falsch verstanden oder du hast das mißverständlich erklärt: ein gotoAndStop ist ein Sprung zu einem Frame mit einem gleichzeitigen Stop dessen Zeitleiste.

Danach läuft nichts weiter auf dessen Zeitleiste ab mit Ausnahmen von MC-Animationen mit eigener Zeitleiste. Ein stop-Befehl stoppt eben nicht alle Zeitleisten automatisch, sondern nur den Ablauf der jeweiligen Zeitleiste. Aber vielleicht meintest du das ja auch...

Die Gültigkeit auch Lebensdauer eines Objektes ist an seine Zeitspur gebunden

Wie gesagt, bei Mehrframe-Programmierung vielleicht. Bei Funktions- oder Objektorientierter Programmierung gilt ein anderer Scope.

[hgseib]

"..nicht unwidersprochen stehen lassen.."
gut! das zeigt dein interesse.

"..Ich versuche diesen ganzen Sprung-Schnickschnack.."
dieser beitrag ist nicht für flash-genies gedacht ;-) die brauchen diesen beitrag freilich nicht. aber so radikal wie du wollte ich nicht auf die möglichkeiten des tweenens verzichten.

"..mit einem gleichzeitigen Stop dessen Zeitleiste.."
mir ist wiederholt aufgefallen, das leute so eine erklärung mit einem programmstopp assoziieren. und ich ertappe mich auch selbst, das ich eher ein gotoAndPlay mit einem stop im zielframe benütze, anstatt eines gotoAndStop. und wer hat sich noch nicht gefragt, ob er nun das stop lieber oben hinreibt oder am script-ende.

Zeitleiste: ist das ganze ding.
eine Zeitspur (ich rede nur von den spuren - leider kann ich hier kein bild mit reingeben) ist ein kästchen in der zeitleiste, bzw. mehrere zusammenhängende kästchen.
das atom-modell stimmt auch nicht, dient dennoch zur erklärung. und der haken an zeitleiste/ zeitspur ist, dass das garkeine objekte sind. die existieren eigentlich garnicht, genauso wie die bibliothek nicht existiert. aber für den "normale" flasher sind das die realen objekte, die er er- und einstellt.

"..Ein stop-Befehl stoppt eben nicht alle Zeitleisten automatisch.."
wo hätte ich denn das geschrieben?

"..Bei Funktions- oder Objektorientierter Programmierung gilt ein anderer Scope.."
vollkommen richtig! das scheint mir auch ein hauptgrund zu sein, warum "reine" programmierer grosse probleme mit flash haben und es deshalb erst garnicht anfangen.
Wenn ich hier den begriff objekte verwendet habe, dann im sinne von flash-objekten und nicht im sinne von OOP.

aber so ratikal wie du wollte ich nicht auf die möglichkeiten des tweenens verzichten.

Radikal verzichten tue ich auch nicht... Ich versuche allerdings möglichst viel zu programmieren, damit möglichst viel wiederverwendbar ist. Bei Tweens ist das leider nicht so der Fall. Und wenn gar nicht anders machbar, kommt der MC in die Bibliothek und wird erst zur Laufzeit attacht.

Mit Tweens ist das halt wie bei Star Wars mit der Dunklen Seite der Macht: sie sehen einfach und verführerisch aus, das dicke Ende kommt dann später