Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: text inputs in view stop working when adding code to PrepareViewsCommand  (Read 9591 times)
MrMastermind
Newbie
*
Posts: 3


View Profile Email
« on: April 06, 2010, 01:07:00 »

Hi,

I have PrepareViewsCommand which sets up my mediators and views. Everything is working fine. But as soon as I add any line of code, my text inputs in my portal view cannot be editted anymore. I added a simple trace("TEST") line and it stops functioning. Anyone have any suggestions?

The project is based on Flex 3.4 and uses a code behind structure.

Here's the code of the PrepareViewsCommand:

:
package nl.tinqwise.coachandcoach.controller
{
import nl.tinqwise.coachandcoach.view.NavigationMediator;
import nl.tinqwise.coachandcoach.view.PortalMediator;
import nl.tinqwise.coachandcoach.view.TemplateContainerMediator;
import nl.tinqwise.coachandcoach.view.components.NavigationComponent;
import nl.tinqwise.coachandcoach.view.components.NavigationComponentClass;
import nl.tinqwise.coachandcoach.view.components.PortalComponent;
import nl.tinqwise.coachandcoach.view.components.PortalComponentClass;
import nl.tinqwise.coachandcoach.view.components.TemplateContainerComponent;
import nl.tinqwise.coachandcoach.view.components.TemplateContainerComponentClass;

import org.puremvc.as3.multicore.interfaces.INotification;
import org.puremvc.as3.multicore.patterns.command.SimpleCommand;

import flash.display.DisplayObjectContainer;

/**
* @author Marco
* creates view components
* add's them to the displaylist
* creates mediators
* registers the mediators
*/
public class PrepareViewsCommand extends SimpleCommand {


private var _mainContainer : DisplayObjectContainer;

override public function execute( note : INotification ) : void
{
// Main container

trace("TEST");

_mainContainer = DisplayObjectContainer(note.getBody());

// States and pages


//Add Portal component and Mediator
var portal : PortalComponentClass = new PortalComponent() as PortalComponentClass;
_mainContainer.addChild( portal );
var portalMediator : PortalMediator = new PortalMediator( portal );
facade.registerMediator( portalMediator );

var templateContainer : TemplateContainerComponentClass = new TemplateContainerComponent() as TemplateContainerComponentClass;
_mainContainer.addChild( templateContainer );
var swfContainerMediator : TemplateContainerMediator = new TemplateContainerMediator( templateContainer );
facade.registerMediator( swfContainerMediator );

/*
* Add TipBoek component and Mediator
* Keep at bottom of this command to overlay other components
*/
// var tipBoek : TipBoekComponentClass = new TipBoekComponent() as TipBoekComponentClass;
// _mainContainer.addChild( tipBoek );
// var tipBoekMediator : TipBoekMediator = new TipBoekMediator( tipBoek );
// facade.registerMediator( tipBoekMediator );


/*
* Add Navigation component and Mediator
* Keep at bottom of this command to overlay other components
*/
var navigation : NavigationComponentClass = new NavigationComponent() as NavigationComponentClass;
_mainContainer.addChild( navigation );
var navigationMediator : NavigationMediator = new NavigationMediator( navigation );
facade.registerMediator( navigationMediator );


}
}
}
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: April 07, 2010, 08:01:45 »

I don't see anything in particular wrong with this, certainly nothing that would seize up text box.

You mention using a code-behind structure. This isn't a recommended practice with PureMVC. How are you implementing it? Is it in the form of Mediators that know everything about the internal structure of their components and puppeteer them? Could it be an action that one of these Mediators takes?

BTW, if you're using Flex, you should try using the debugger to set breakpoints and follow the thread of execution. IMHO, trace statements are a stone age approach to debugging.

-=Cliff>
Logged
Pages: [1]
Print