Listener Funktion ohne Listener ausführen

[Sebbal]

Hallo,

wie so viele, fange ich jetzt auch an in AS 3.0 zu arbeiten, nachdem ich mich in 2.0 ganz gut auskenne.

Ich habe bisher schon verstanden, dass man für eigentlich alles Listener verwendet und das funktioniert auch. Jetzt aber meine Frage:
Wenn ich bei einem Knopf mit einem Listener ein CLICK abfrage und dann meine Funktion ausführe, ist es dann auch irgendwie möglich, diese Funktion von einer anderen Funktion ausführen zu lassen? Das Problem ist ja, dass ich theoretisch den MouseEvent.CLICK mitgeben müsste.

first_level.erlebnis.icon.addEventListener(MouseEvent.MOUSE_DOWN, setup_erlebnis);

function setup_erlebnis(evt:MouseEvent):void{
trace("Funktion ausgeführt");
}

setup_erlebnis;

Geht das nicht irgendwie? Sonst müsste ich die gesamte Funktion (natürlich mehr inhalt als hier im Beispiel) kopieren und als generelle Funktion verfügbar machen, hätte somit also unnötige Dopplungen im Code.

Vielen Dank schonmal!

[nky]

du kannst die events auch manuell dispatchen..
such mal nach manually dispatch event bei google.

sorry weiss grad aussem kopf nicht wies geht

gruß
nky

[Sebbal]

Super, danke...all meine Google Sucheingaben brachten keine Lösung, aber deine war super ;-)

Für alle die es interessiert:

first_level.erlebnis.icon.addEventListener(MouseEvent.MOUSE_DOWN, setup_erlebnis);

function setup_erlebnis(evt:MouseEvent):void{
trace("Funktion ausgeführt");
}

setup_erlebnis(new MouseEvent(MouseEvent.CLICK));

Man tut einfach so, als hätte es einen MouseEvent gegeben. Klasse!

[mooseMash]

du kannst auch einfach schreiben:

PHP-Code:

setup_erlebnis(null); 


[Sebbal]

stimmt, das geht auch :-) viel einfacher.... Danke

[nky]

cool das ist logisch, war mir aber irgendwie nie bewusst thx !

[hmpf]

eine etwas bessere Lösung wäre, den Event Parameter in der Funktion optional zu machen

function setup_erlebnis(evt:MouseEvent=null):void{
trace("Funktion ausgeführt");
} 

[Omega Psi]

Eine noch besserere Lösung:

someMagic();
 
function eventListener(event:Event):void
{
    someMagic();
}
 
function someMagic():void
{
    trace("Some magic happens here");
} 

[hmpf]

Und warum ist das noch besser? Sieht so erstmal umständlicher aus als =null

[Omega Psi]

Es ist besser weil Eventlistener bestimmte Typen von Funktionen sind. Sie werden quasi in den Scope der registrierenden Klasse übernommen, so das die IEventDispatcher Instanzen die Funktionen direkt aufrufen können. Da die Klassen nun direkte Kontrolle über die Funktionen haben, obwohl sie ihnen nicht gehören ist es im Hinblick der Kaspelung besser/sauberer die entsprechenden Funktionen nur als definierte Schnittstellen zu verwenden für Kommunikationen mit anderen Klassen über Events.

[hmpf]

Zitat von Omega Psi

Da die Klassen nun direkte Kontrolle über die Funktionen haben, obwohl sie ihnen nicht gehören

Ok, danke. Das ist soweit einleuchtend. Aber hat das einen praktischen Nachteil?

Zitat von Omega Psi

ist es im Hinblick der Kaspelung besser/sauberer die entsprechenden Funktionen nur als definierte Schnittstellen zu verwenden für Kommunikationen mit anderen Klassen über Events.

Sollte man also mit allen Funktionen, die man in Listenern registriert, so vorgehen?
Wenn aber der Listener in derselben Klasse registriert wird, die auch die Funktion enthält, macht es ja keinen Unterschied.

[Janoscharlipp]

Praktisch macht das keinen Unterschied, aber dennoch würde ich Omega Psi auf jeden Fall zustimmen.
Der Punkt ist einfach, dass du eine Funktion als Listener-Funktion konzipiert hast, sie dann auf andere Art zu verwenden ist inkonsistent, und daher verwirrend.
Auch ein Grund ist, dass man (zumindest in der AS Welt) Listener-Funktionen meist anhand des Events, das sie behandeln, benennt. (Kommt vielleicht noch aus der AS1 Zeit, als Listener eigentlich nur normale Funktionen mit einem speziellen Namen waren) Der Name einer normalen Methode sollte aber ausdrücken, was die Methode macht. Der Vorschlag von Omega Psi wird beiden Konventionen gerecht.

[Omega Psi]

Wenn du die null Referenz nicht expizit erlaubst, hast du in meinen Augen ein paar Vorteile.

Es macht das Testen einfacher, weil du nicht auf Events angewiesen bist. Ausserdem weichst du so nicht die API auf, da die Signaturen keine null Referenz erlauben. Und die Signaturen kommunizieren ihre Funktionalität besser.

[hmpf]

Was genau sind jetzt Signaturen, die Funktionsnamen?

Zum Testen habe ich in dem Projekt, an dem ich gerade arbeite, in den Funktionen den Event mit =null optional gemacht... funktioniert hat es jedenfalls ganz gut .
Aber es ist auch mein erstes richtiges AS3 Projekt. Änderungen an meinem Programmierstil übernehme ich gerne, wenn ich verstehe wieso. Mit Design Patterns werde ich mich auch noch intensiv beschäftigen. Momentan fehlt mir nur die Zeit.

[Omega Psi]

Signaturen sind die Funktionsdefinitionen nach außen:

<[Optional: override]> <Sichtbarkeitsmodifikator> <Name der Funktion> (<Menge der Argumente>): <Typ des Rückgabewerts>

Wenn nun eine Funktion null explizit erlaubt, mag das praktisch sein. Aber in den Fällen von EventListenern ist das eben nicht so schön.

Mit Design Patterns hat das ganze nichts zu tun, es ist viel mehr ein Idiom der ActionScript Sprache.