Z order is not work with Loader

Haxe
#1

(Flash target)
Z order is not work with Loader. I guess it was wrong above OpenFL 4.5.2.

Simple test code:

  1. child
class Main extends Sprite 
{

	public function new() 
	{
		super();
		
		// Assets:
		var circle = Assets.getBitmapData("img/bottom.png");
		var bitmap = new Bitmap(circle);
		this.addChild(bitmap);
	}

}
  1. loader
class Main extends Sprite 
{
	private var loader:Loader;

	public function new() 
	{
		super();
		this.name = "main";
		
		Security.allowDomain("*");
		Security.allowInsecureDomain("*");
		
		loader = new Loader();
		loader.contentLoaderInfo.addEventListener(Event.COMPLETE, onComplete);
		loader.name = "bottom.loader";
		loader.x = 20;
		
		var request = new URLRequest("child swf url");
		loader.load(request);
	}
	
	private function onComplete(event:Event):Void
	{
		loader.contentLoaderInfo.removeEventListener(Event.COMPLETE, onComplete);
		addChild(loader);
		
		var bitmap = new Bitmap(Assets.getBitmapData("img/up.png"));
		bitmap.name = "top.bitmap";
		addChild(bitmap);
		
		var idx = getChildIndex(bitmap);
		trace("bitmap index: " + idx, "parent name: " + bitmap.parent.name);
		
		idx = getChildIndex(loader);
		trace("loader index: " + idx, "parent name: " + loader.parent.name, "x value: " + loader.x);

	}
}

Result:
image

Trace result:
Main.hx:47: bitmap index: 1,parent name: main
Main.hx:50: loader index: 0,parent name: main,x value: 20

Loader’s x value is 20 but not work. But, when I down grade OpenFL to 4.5.2(Lime 3.5.2), everything is ok.
image

How can I fix this error?

#2

Have you tried putting addChild( loader ); after addChild( bitmap ); ?
Or addChildAt( bitmap, 0 ); ?

#3

Yes I did. But, not changed anything.

#4

So the trace says the index of up.png is 1 when you can see it’s behind the circle?

#5

I reproduced your structure, but I had a different problem – the main parent SWF loads itself, endlessly. It never loads the child.

The child SWF defines class names (ApplicationMain, Main, etc) that are the same names as the parent. As a result, these get merged, so instantiating the child SWF triggers the parent existing classes, resulting in an infinite loop.

I was able to solve this by using new LoaderContext (true, new ApplicationDomain ()) in the second parameter of the loader.load method, allowing the SWF to have a different application domain, eliminating the conflict.

We could consider a change to how we generate Flash content, in order to make these automatically generate classes unique, so as to prevent collisions, but that will require additional work to sort out.

If you need to load a child SWF, then get references to its loaded classes, you should keep a reference to the new ApplicationDomain you create, and use that to getDefinition

Loader crushes after loaded
#6

Very very big thanks!!!

1 Like