robotlegs nativeWindow dispatch Probleme

[speedjunkie]

Hi Community und danke fürs Lesen,

ich weiß nicht ob es die richtige Rubrik ist, gerne auch verschieben.

Ich schreibe eine kleine Anwendung mit [robotlegs] und es läuft eigentlich wunderbar.

Nur wenn ich mit einem zusätzlichen Fenster arbeite, kommt kein Event bei dem Mediator an der
für meinen View im zusätzlichen Fenster zuständig ist.

Ich habe bei nativeWindow.stage ein DisplayObjectContainer als Child und der ist mein Context fürs neue Fenster.

Der Mediator, der das Event erhalten soll, ist mein ContextMediator fürs zusätzliche nativeWindow.

Szenario:

• Fenster poppt auf
• addChild( DOC );
• Context vom DOC wird registriert
• Mediator vom contextView wird registriert --> onRegister --> traces ok!!
• onRegister --> eventMap.mapListener(eventDispatcher, VirginEvent.COMPLETE, preview, VirginEvent);

dann:

• Event wird abgefeuert vom Service extends Actor --> eventDispatcher.dispatchEvent(new VirginEvent(VirginEvent.COMPLETE, _bitmapData));

Nichts passiert!

Wenn ich beim Actor nachfrage:

FlashConnect.trace(eventDispatcher.hasEventListener(VirginEvent.COMPLETE)); // true
FlashConnect.trace(eventDispatcher.willTrigger(VirginEvent.COMPLETE)); // true 
 

Wäre nett, wenn jemand einen kleinen Rat für mich hat. Außer wenn ich mit einem nativeWindow arbeite ist alles in Ordnung.

Gruß Daniel

[malthoff]

Mir ist die Beschreibung etwas wirr. Ich vermute ein Problem in der Reihenfolge, in der die Elemente die Bühne betreten. Kann es sein, dass zu dem Moment, wo der Mediator des einen Fensters das Event schmeisst, dass andere noch nicht auf der Bühne ist UND sich für das Event angemeldet hat?

Mit "etwas wirre Beschreibung" meine ich Deine benutzen Begrifflichkeiten. Eine Robotlegsanwendung hat im Normalfall einen Context und jede zusätzliche View seinen Mediator. Wenn Du schreibst: "Fenster poppt auf und dann erst addChild DOC... ist schon die Reihenfolge "falsch", zumindest irreführend. Vorallem wenn danach erst der Context des DisplayObjectContainers registriert wird - was ist das?

Das ist jetzt nicht angreifend gemeint sondern soll Dir zeigen, dass ich (und eventuell auch andere) den Ablauf so nicht nachvollziehen können.

[speedjunkie]

Hi malthoff,

ich bin der Beschreibung von Joel Hook gefolgt, so das ich für die zweite Stage ein eigenen Context anlegen muss. Wenn ich es richtig verstanden habe.

Das zweite Fenster poppt durch User Interaktion auf, wenn der Ablauf anders ist, ist es nicht da also der Speicher frei.

Meinst Du ich sollte die zweite Stage und die DisplayList schon anlegen und dann lieber nur mit activate(); arbeiten und alles in einem Context.

package …
{
    import …  
    /**
     * ...
     * @author Daniel
     */
    public class TransformStartupCommand extends Command 
    {
        [Inject]
        public var _bytesLoader:BytesLoaderForTransformTheView;
        
        override public function execute():void 
        {         
            Virgin.instance; // das ist mein zweites NativeWindow
            
            _bytesLoader.loadBytes(); // das mein Service
            
            super.execute();
            return;
        }
        
    }
 
} 

[speedjunkie]

Nachtrag:

Definitiv ist es so das View Mediator Paare bei einer Anwendung mit nur einem Context nicht gemapt werden, wenn sie einer anderer Stage angehören. Ich hatte erst mit dem Event System von Haus aus gearbeitet, um zwischen den beiden Contexts zu kommunizieren, die Abweichung vom Framework hat mir nicht gefallen und ich habe mich für das Signal-Slot-Konzept entschieden und eine Art Signal Router gebastelt.

Das funktioniert wunderbar!!!

STUFF

• Performance
• Signal Command Map
• SignalMediator and SignalMap