setInterval bei wechselnden Container Inhalten

[Basileus]

Also,

auch ich hätte da mal ein Problem:

Komplex verschachtelte Seite mit Containern und Untercontainern und Unteruntercontainern und ....
Ganz unten in der Hierarchie definiere ich einen setInterval mit 8000 Millisekunden, der ruft eine Funktion ebenfalls auf der untersten Ebene der Struktur auf.
Funktioniert wunderprächtig. Nur kann man mit der Navifgation den kompletten Bereich, in dem sich setInterval und die Funktion abspielen, entladen und durch etwas anderes ersetzen. Nach meiner Logik sind nun die Funktion und der Interval -der mit Identifier auf der eben entladenen Ebene registriert war- weg. Stimmt aber nicht.
Wenn nun im Obercontainer der komplett andere Inhalt erscheint, was passiert dann nach 8000 Millisekunden, na ? Klar, der komplette Flashfilm entlädt sich und übrig bleibt ein weisses Feld im Browserfenster.

mir fallen auf Anhieb und spätnachts nur zwei Lösungswege ein:

1.) Interval gegen onEnterFrame mit Millisekundencounter ersetzen - unschön
2. bei Verlassen des Komplexes clearInterval aufrufen - fast unmöglich , weil es zuviele Wege gibt, den Komplex zu verlassen, und zuviele Intervals und und und


... wäre cool, wenn mal jemand antworten könnte ..

Grüsse
B

 

[Tobias Menzel]

Hi,

ein ähnliches Problem hatte ich neulich auch - allerdings nicht mit setInterval, sondern mit einem MouseListener, der nach dem Entladen (bzw. Ersetzen) eines Clips weiterhin gültig war und fröhlich einen anderen Clip mit dem selben Instanznamen auf das Mausrad reagieren ließ... ob ich Deine Situation ganz verstehe, kann ich nicht sagen; relevante Code-Ausschnitte wären von Vorteil.

Ausprobiert habe ich eben folgendes:
- entlade ich den Clip mit removeMovieClip, ist der Intervalhandler ebenfalls weg (der wird wohl in der Instanz gespeichert). Dann ist mein Container zwar auch perdu, aber ich kann mir ja bei Bedarf einen neuen erstellen.

- entlade ich den Clip mit unloadMovie, bleibt der Handler in der Tat bestehen und versieht fröhlich seinen Dienst.

Ich weiß natürlich nicht, was Du für Eingriffe in Deiner Struktur vornehmen kannst, aber ich würde den Intervalhandler einfach auf einer statischen Stufe (z.B. _root; wenn Du mit _lockroot arbeitest,gib den Subclips eben eine Referenz auf _root mit) anlegen, und beim Wechsel per Menü die betroffenen Handler löschen (wenn die Handler eindeutige Namen haben, die z.B. auf den Instanznamen der Subclips basieren, kannst Du den zu löschenden Handler leicht ausfindig machen). Du sagst, es gibt zu viele Wege, den Komplex zu verlassen - allerdings würde ich eben diese Strukturen möglichst zentral bündeln, so dass ein SubClip, der einen anderen ersetzt, dies nicht direkt, sondern über entsprechende Funktionen auf _root erledigen muss.

Ein Einblick in Teile der Datei(en) wäre hilfreich, allerdings kann ich verstehen, wenn Du die nicht herausgeben kannst.

Gruß

P.S.: ich sage "Handler", meine aber "Identifier".

EDIT: hmm, das hat mich nun in der Tat nicht losgelassen, und ich habe noch mal ein wenig rumprobiert. Herausgekommen ist folgende kleine Klasse, die Dir vielleicht weiterhilft (diverse Tests hat sie jedenfalls bestanden):

class smartInterval {

	var OBJ:Object;
	
	function smartInterval(interval:Number, fn:Function, dest:MovieClip) {
		OBJ = new Object();
		OBJ.DC = dest;
		OBJ.FN = fn;
		OBJ.timestamp = getTimer();
		OBJ.DC["stamp" + OBJ.timestamp] = OBJ.timestamp;
		OBJ.interval = function() {
			if (this.DC["stamp" + this.timestamp] == this.timestamp) {
				this.FN();
			} else {
				clearInterval(this.IV);
			}
		}
		OBJ.IV = setInterval(OBJ, "interval", interval);
	}
}

Das ist ein Intervall, dass sich selbst zerstört, wenn der Ziel-MovieClip nicht mehr in der Originalform (bei Instanzierung der Klasse) vorliegt. Aufruf z.B.:

var iv1 = new smartInterval(8000, function() { doSomething(); }, this);

function doSomething() {
    // hier irgendwas
}

P.S.: Was genau spricht eigentlich gegen etwas onEnterFrame-basiertes? Bei 8000 Milisekunden dürfte das doch hinreichend genau sein.

P.S. II: Nachtrag: Ich habe grade festgestellt, dass Du das Intervall in der Klasse nicht einmal löschen musst; sobald die Referenz auf die Klasse zerstört wird, ist das Intervall auch dahin. Du kannst also die "stamp"-Variable und die dazugehörige Abfrage entfernen (ich habe es drin stehen lassen, um meinen Gedankengang zu dokumentieren)!
.

 

[Basileus]

Echt Klasse

Funktioniet auch einwandfrei, obwohl ich den Verdacht hege das er trotztdem weitermacht, weil meine Festplatte weiterrattert (ging um das frequente laden von Bildern).
Leider geht das ganze nicht ohne AS 2.0 und da muss ich passen, ich konnte den Kunden gerade mühsam zu Player Version 6.0 überreden, also muss ich wohl doch auf ein onEnterFrame zurückgreifen, das ich eigentlich wegen mangelnder Code Ästhetik ablehne.
Aber das Ding kommt in die Sammlung !

Grüsse, und Danke

B

 

[Tobias Menzel]

obwohl ich den Verdacht hege das er trotztdem weitermacht, weil meine Festplatte weiterrattert

Ja? Dann ist das aber ein Fehler im GC des Flashplayers. Außerdem habe ich trace-Aktionen in die "interval"-Funktion der Klasse gesetzt, die nach dem Derefere zieren nicht mehr ausgeführt wurden... hmm. Eine Intervallklasse mit onEnterFrame war übrigens mein erster Versuch zu dem Thema, aber auch die benötigt AS2.0 - und der entsprechende Prototype würde zumindest getTextHighestDepth() benötigen (oder doch recht unsicher sein).

Gruß
.

 

[Basileus]

Na,

auf jeden Fall ne coole Klasse, wir sollten vielleicht bald ne Extra - Ecke für Klassen freischaufeln....

Ich hab das Problem dann 'klassisch' mit einem:

Player = function ()
{
	Namen = new Array ();
	for (i in this)
	{
		Ziel = eval (i);
		if (Ziel.ID == true)
		{
			Namen.push (Ziel._name);
			trace (Ziel._name);
		}
	}
	var WalkVCR;
	this.createEmptyMovieClip ("Holder", 1);
	Holder.onEnterFrame = function ()
	{
		meine_Zeit = new Date ();
		Zeit = meine_Zeit.getTime ();
		if (!altZeit)
		{
			altZeit = Zeit;
		}
		if (Zeit - altZeit >= 8000)
		{
			Callx ();
			altZeit = Zeit;
		}
	};
	Callx ();
};
/////////////////////////////////////////////////////////////////////////////////////////
Callx = function ()
{
	trace (_root.counti);
	trace (Namen.length);
	loadMovie (_root.Location + "Bilder/Kapitel" + _root.Aktuell + "/" + _root.Rufer + "/walkthrough/" + Namen[_root.counti], _parent.wcontain);
	setBack (Namen[_root.counti]);
	_root.counti += 1;
	if (_root.counti > Namen.length)
	{
		_root.counti = 0;
	}
};
/////////////////////////////////////////////////////////////////////////////////
setBack = function (Name)
{
	for (i in this)
	{
		Ziel = eval (i);
		if (Ziel.ID == true)
		{
			Ziel.gotoAndStop (1);
			this[Name].gotoAndStop (2);
		}
	}
};

gelöst, ist halt einfach nicht elegant

Grüsse
B

 

[Tobias Menzel]

Jupp. ... aber bekommst Du dann nicht u.U. Probleme mit Deinem "Holder" - oder sind die Stufen der anderen Elemente in "this" bekannt?

Gruß
.

 

[Basileus]

Der Hat Trick liegt in dem ID - alle gewollten MCs haben diese Variable, der Rest nicht. Zum Stoppen einfach Holder unloaden oder den Container komplett neu füllen, damit ist dann alles weg...

Güsse
B

 

[Tobias Menzel]

Ja, ist klar - gefällt mir auch. Was ich meinte war, dass Du den Holder auf Stufe 1 instanzierst und dann eben auf dieser Stufe nicht schon was wichtiges liegen darf... egal, ich sehe ja nur einen Ausschnitt und das Ding ist ja für den individuellen Einsatz bestimmt. Wenn ich allerdings eine externe Klasse oder einen Prototype zur allgemeinen Verwendung schreibe, werde ich mich hüten, irgendetwas auf Stufe 1 zu instanzieren...

Gruß

EDIT (um den Thread nich ewig wachsen zu lassen) @ einen Post tiefer:

äh. Ich meine, immer wenn Du etwas per createMovieClip oder attachMovie instanzierst, musst Du eine Stapelungstiefe (von mir Stufe/Depth genannt) angeben... deshalb ja "getNextHighestDepth" um nichts zu überschreiben...
.

 

[Basileus]

Ah so,

ne, mit Stufen bzw Ebenen arbeite ich nicht sehr viel weswegen das kein Problem ist, solltest du aber die Verschachtelungstiefe meinen.....das ganze spielt sich im 5. Containerglied ab....
Ist aber natürlich weder prototype noch class fähig, weswegen ich es auch unelegant finde...

B