how to call a function of parent object from a loaded swf?

[ziriguidum]

hello,

i have a swf that should be able to load another swf in runtime.

then i would like the loaded swf to call a method of the parent, loader swf, like this:

parent.closeForm;

but when i compile it, it throws this error :

1119: Access of possibly undefined property closeForm through a reference with static type flash.displayisplayObjectContainer.

i´ve tried:

if (parent != stage)
{
	parent.closeForm;
}

so flash won´t run this code at compile time, but it always throws that error.

here is the code of the LOADER swf:

private function loadForm():void
{
	var loader:Loader = new Loader() 
	var mRequest:URLRequest = new URLRequest(formPath);
	loader.load(mRequest);
	loader.contentLoaderInfo.addEventListener(Event.COMPLETE, onFormCompleteHandler);
}
		
private function closeForm():void
{
//  some alpha tween for the LOADED swf, for example, and then onComplete: close somehow
}

however, if i put this code in the LOADED class, it works:

// in init function:
if (parent != stage)
{
	closeBtn.addEventListener(MouseEvent.CLICK, selfClose);
}

private function selfClose(e:MouseEvent):void
{
	parent.removeChild(this);
}

so, how could i write an expression that should call a function of the LOADER swf without having this compile-time error?

Thanks in advance!

[AttackRabbit]

dispatch an event from the child to the parent.

child :

dispatchEvent( new Event( "doSomething" , true , false ) );

parent :

addEventListener( "doSomething" , doSomethingHandler );

private function doSomethingHandler( evt : Event ) : void {
//do something
};

[thorotaxi]

I'd tend to handle this by making the Child SWF a class, then adding an optional parameter to the constructor method of that class by which the parent can be passed. It's fairly easy to call a function of the parent when you pass the parent in...

[AttackRabbit]

passing storing references to things should be the last option. Its memory expensive and performance heavy. Every time you create a reference to something you are declaring that same amount of space in memory , again. Not good O.O.P. Obviously there are some cases when there is no other choice. The event phase in as3 is wonderful. It gives us the ability to have events propagate all the way to the top of our applications , virtually for free. And unless you are popping off hundred of events at a time , there is no performance hit.

[thorotaxi]

Thanks for the tip... that's very helpful. Hadn't thought of using custom events for communication purposes.

[cancerinform]

Here is a component, which does it
http://flashscript.biz/flashas3/path...rectorAS3.html
since this question comes up very often.

[ziriguidum]

Thanks a lot you guys.

The CustomEvent works great! But when I try to do the opposite, that is, to make the parent dispatch an Event to the child to listen, I doesn´t work.

in parent:

		private function openForm():void
		{
			TweenLite.to(formContainer, 1, {alpha:1, ease: Expo.easeOut, onStart: prepareForm});
		}

		private function prepareForm():void
		{
			addChild(formContainer);
			dispatchEvent(new Event("RESET_FORM", true, false) );
			trace ("RESET EVENT DISPATCHED");
			formOn = true;
		}

in child:

addEventListener("RESET_FORM", resetForm);

		public function resetForm(e:Event):void
		{
			trace ("funcao resetForm");
			statusTF.text = "status default text";
		}

the fuction resetForm does not run :/

thanks !

[5TonsOfFlax]

passing storing references to things should be the last option. Its memory expensive and performance heavy. Every time you create a reference to something you are declaring that same amount of space in memory , again. Not good O.O.P. Obviously there are some cases when there is no other choice. The event phase in as3 is wonderful. It gives us the ability to have events propagate all the way to the top of our applications , virtually for free. And unless you are popping off hundred of events at a time , there is no performance hit.

While I agree that event dispatch is probably the most elegant way to handle this, I believe you are wrong about the memory implications. Declaring a variable will not reserve space for the object that the variable will point at, instead it only reserves enough for the memory pointer. Memory for the actual object is only allocated upon the new Whatever() call. It is probably actually more efficient to have a direct reference to the object you want to call a method on than to dispatch and listen for events (event creation is object creation is memory allocation is relatively slow), but having the actual references couples the classes together more tightly.

[5TonsOfFlax]

ziriguidum, the reason the even dispatch model does not work the other way is that events only bubble upward through the display list. That is, the parent can intercept events originating in the child, but the child never hears events originating in the parent. You can still use events, but you have to add the event listener to the instance which will actually dispatch the event you are interested in.

child:

parent.addEventListener("RESET_FORM", resetForm);

		public function resetForm(e:Event):void
		{
			trace ("funcao resetForm");
			statusTF.text = "status default text";
		}

Since parent is a DisplayObjectContainer, it is an EventDispatcher, and has the addEventListener method. You must be careful though. This depends on getting the correct parent. The code above assumes that the child is a direct child of the parent. If your child swf is still in its Loader, then you would have to use parent.parent instead.

[ziriguidum]

excellent!

parent.addEventListener solved, i used that in parent (formContainer is the child):

formContainer = loadEvent.currentTarget.content;

Thanks a lot !

[neznein9]

event creation is object creation is memory allocation is relatively slow

Hey Flax - I've been thinking about this same issue lately. I'm working with some classes that throw a lot of empty events and I'm considering storing one event object as a class constant and dispatching that instance over and over. It seems like no one else does that and I'm not sure why - any thoughts?

[AttackRabbit]

Its just bad O.O.P. If You want to hackishly pass references to things go for it. Direct referencing you are creating dependencies. If you ever wanted repurpose the swf for example , load it something that doesnt care about this event cycle , you better hope the new parent has a method in it that matches the one you are calling in the child, on the reference you passed in. With events , it doesnt matter, that swf can dispatch the event and whoever needs to hear it will , or no one will. Thats why there is a EventDispatcher , to get away from the old hacky as2 approach of using callback after callback , after to reference to a parent blah. The mentality shouldn't be , hey lets just get this thing to work. Its should be , hey lets do this the best way we can.

Oh and on a side note , if you create a reference to a parent object in a child , you will want to set that reference to null when you remove that child from the display list. Although the child is removed , that reference will still be in memory. Adobe says that is should be marked for garbage collection, but they admit as a best practice , kill everything , all the time.

[jAQUAN]

I tend to agree with you AttackRabbit but callbacks aren't really that bad. Check out the HYPE framework linked in my footer. It's one of the latest from some of the greatest and there isn't an event to be found. The authors purposefully avoided the load that comes with event pooling and opted for callbacks. In certain situations, it's not that bad provided of course that you carefully nullify.

I quite like the idea of creating a single event object and re-sending it but I honestly don't know enough about the event scheme to say weather or not that creates reference spaghetti. If you follow Robert Penner's tweets, he's been doing a lot of research into that area and is working on alternatives. Check out his Signals project.
http://www.robertpenner.com/flashblog/

EDIT: Just talked to the man, a single event object, as long as its a custom event and implements clone(), you're all good.

[5TonsOfFlax]

AttackRabbit, let me clarify. I completely agree that events are the way to go in situations like these. They are more elegant, less coupled, and fit in better with OOP. I was just commenting on the notion of strict efficiency. Personally, I'll sacrifice a couple of microseconds for elegance any day.

nezNein9, I know I've played around with re-using a single event, or more generally event pooling, but I don't remember whether the gains were noticeable. I'm not sure everywhere the clone method gets called. You might want to try it and put a trace in clone so you can see whether it's called. I wonder if clone can be overridden to simply return the same event instance. I don't see why not.

[AttackRabbit]

I think 5tons made a good point though. In the web world , unless you are dealing with some serious levels of data , ie a sears catalog , where you have to parse a 250,000 line xml doc to generate image objects as children , we are speaking in the 10th of a second range as far as process time. And yes in most RIA scenarios , ref's vs events from a physical memory standpoint are probably not going to make a difference. I understand the referencing an object doesn't create a new one , but its having to re access that same chunk of data , more frequently and at a much higher level then if it was solely event driven. The events are handled deeper within the framework of a flash movie , in the more primitive areas of the compiled code.