Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Adobe AIR Development

Reply
Contributor
Posts: 20
Registered: ‎07-01-2011
My Device: BlackBerry PlayBook
My Carrier: n/a

Events not working as expected

I'm having a bit of trouble figuring this one out Smiley Sad

 

Since I've upgraded to fb 4.5, sdk 1.1, latest AIR I've noticed a difference with my dialogs.

 

I have a dialog class that takes up the full screen.  It swallows some events (eg: MOUSE_DOWN - note: useCapture=false).  This is because I don't want say a list behind it to get the event when the dialog is displayed.

 

This all worked fine previously. However, since the upgrade, I've noticed "holes" in the dialogs.  What I mean by this is if I have a trace in all my event handlers, normally my dialog gets the event and everything works. Occasionally at some spots on the dialog, the dialog doesn't get the event at all - it's raised in the list behind it!

 

Could someone give me some insight on this? It's my understanding that the control(s) displayed above the others should receive the event first, unless your talking about the capture phase of events.

 

 

Developer
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: Events not working as expected

"Above the others" means (in terms of z-layer) "added afterwards", but that actually not directly relevant to whether something gets the event or not, as far as I know.

I believe how it works is that the framework identifies which specific child is directly under the event coordinates, taking into account which one is "on top" (i.e. of any two objects in the same parent, which one was added later) , and also transparency (and maybe other complications).

Then it begins the CAPTURE phase, sending the event first to the stage, which is the root of the tree and thus the ultimate ancestor of every object in the display list, then down through the appropriate children up to the immediate parent of the originally identified target.

After that, the AT_TARGET phase is executed, where bubbling=false and useCapture=false. That sends the event to the target itself.

After that, the BUBBLING phase executes, which sends the event again to each ancestor, from the target's parent back up to the stage, with useCapture=false and bubbling=true this time.

If you are trying to completely prevent anything behind your dialog from getting it, including the stage, you have to first know whether the relevant phase in your case is the capture phase or the bubbling phase, and secondly you'd probably have to be sure to call stopPropagation() on the event at the right point.

I'm not sure that directly helps, but maybe it will at least set the "stage" for the rest of the discussion. ;-) It's hard to tell what the issue may be without a clearer picture of your display list organization, and what you're doing with the event to prevent it bubbling back up, etc.

Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
Contributor
Posts: 20
Registered: ‎07-01-2011
My Device: BlackBerry PlayBook
My Carrier: n/a

Re: Events not working as expected

Yup, all that jives with how I'm interpreting things.

 

I've got the following setup:

 

stage->Sprite1->Sprite2->List

 

and

 

stage->Sprite1->Dialog(Sprite3)

 

I've numbered the sprites in there according to which are the same instance. Ie: Sprite2 and Dialog(Sprite3) are actually added to the same parent, Sprite1.

 

The dialog is added later than the Sprite2, so it shows up above when both are displayed.

 

I've put an event handler for MOUSE_DOWN on the List, and also on the Dialog.  The Dialog does an e.stopPropagation().  It's also the full size (1024x600).  Both handlers have unique trace statements printing out who's getting what.

 

What's happening is that as I click around with the dialog visible, I mostly get Dialog.MOUSE_DOWN events as expected.  However, there are a few spots I can consistently only receive List.MOUSE_DOWN, and Dialog.MOUSE_DOWN doesn't even trace print.  Isn't this a bit wierd?

 

Like technically, with Sprite2 and List not even being in the same parent-child hierarchy as Dialog(Sprite3), I'm not even sure why it's receiving anything b/c capturing, bubbling, ... are usually restricted to the parent/child lines no? (eg: it would surprise me less if stage got something, but Sprite2->List?)

 

 

 

 

Contributor
Posts: 20
Registered: ‎07-01-2011
My Device: BlackBerry PlayBook
My Carrier: n/a

Re: Events not working as expected

Sorry, I forgot to mention, everything I'm talking about here is bubbling/target. *None* of the event handlers are useCapture=true.
Developer
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: Events not working as expected

Quick followup for anyone interested in this. Jason and I talked via Video Chat and he's going to attempt to shrink this down to a standalone sample that reproduces the problem. We looked at the issue a number of ways and so far it's definitely looking like a bug, and specifically one that's new with SDK 1.1.0/AIR 2.7/Flash 10.3/latest FB, though it's unclear yet which part of that stack is at fault.

Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
Contributor
Posts: 20
Registered: ‎07-01-2011
My Device: BlackBerry PlayBook
My Carrier: n/a

Re: Events not working as expected

package
{
	import flash.display.Sprite;
	import flash.events.MouseEvent;
	
	import qnx.ui.data.DataProvider;
	import qnx.ui.listClasses.List;
	
	[SWF(height="600", width="1024", frameRate="30", backgroundColor="#FFFFFF")]
	
	public class test extends Sprite
	{
		public function test()
		{
			var dp:DataProvider = new DataProvider();
			for(var i:int = 0; i < 100; i++)
				dp.addItem({label: i.toString()});
			
			var list:List = new List();
			list.dataProvider = dp;
			list.width = 400;
			list.height = 400;
			list.x = 30;
			list.y = 30;
			
			var sprite1:Sprite = new Sprite();
			sprite1.addChild(list);
			
			addChild(sprite1);
			
			//----------------------------------------------
			var sprite2:Sprite = new Sprite();
			sprite2.graphics.beginFill(0x000000, .7);
			sprite2.graphics.drawRect(0,0,1024,600);
			sprite2.graphics.endFill();
			sprite2.width = 1024;
			sprite2.height = 600;
			sprite2.x = 0;
			sprite2.y = 0;
			
			addChild(sprite2);
			
			//----------------------------------------------
			list.addEventListener(MouseEvent.MOUSE_DOWN, function():void {trace("list");});
			sprite2.addEventListener(MouseEvent.MOUSE_DOWN, function():void {trace("sprite2");});
		}
	}
}

You'll notice if you start at the top of the list (it's behind the transparent overlay), and keep clicking all the way down there will be some spots (eg: close to between the list elements) where only the "list" will print and not "sprite2" as expected.

Developer
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: Events not working as expected

I ran through a series of "regression" tests with that code, on older SDKs and simulators.  Here are the results:

 

  1. SDK 1.1.0 / sim 1.0.6: fail (as Jason originally noted)
  2. SDK 1.0.1 / sim 1.0.6: fail
  3. SDK 0.9.4 / sim 1.0.6: fail
  4. SDK 0.9.4 / sim 0.9.4: PASS (i.e. the List never sees the clicks)
  5. SDK 1.1.0 / OS 1.0.6: fail (i.e. does fail on real hardware too)
  6. SDK 1.0.2 / sim 1.0.2: PASS

To me that says the issue is not with the List code itself, but is related to the runtime -- either AIR 2.7 or Flash 10.3 has a problem here.

 

I also checked with one of my own apps, where a ToggleSwitch lies on the main screen, and when I pull down my top-swipe menu I put a semi-transparent "intercept" sprite over top of the main screen to dim it.  The intercept sprite should catch MOUSE_DOWN and trigger hiding of the menu.  Instead, if I click in the right places, in particular just inside the toggle switch but very near its left edge, that button gets the event but my intercept sprite does not, and the menu stays on top.

 

I suspect many apps could be suffering from the same problem.

 

Looks to me like a bug in AIR 2.7 or Flash 10.3... the issue is certainly not limited to the qnx List control anyway.


Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
BlackBerry Development Advisor
Posts: 15,700
Registered: ‎07-09-2008
My Device: BlackBerry PRIV
My Carrier: Bell

Re: Events not working as expected

I have been able to reproduce this and have logged it in Issue Tracker here:  https://www.blackberry.com/jira/browse/TABLET-276

 

A big thank you to all on thread for reporting and troubleshooting this so thoroughly.

Mark Sohm
BlackBerry Development Advisor

Please refrain from posting new questions in solved threads.
Problem solved? Click the Accept As Solution button.
Found a bug? Report it using Issue Tracker
Developer
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: Events not working as expected

Thanks for filing that, Mark.

I wonder if this is related to "cacheAsBitmap" and friends? I believe the List control (or the CellRenderers anyway) use that to optimize scrolling and such. I could imagine the ToggleSwitch does the same.

If Flash 10.3 was messed up in the graphics department enough, it might be getting confused about the z-ordering of stuff when some items that should be below others are cached as bitmaps.

Pure speculation... just an idea for someone who may be trying to find a workaround. Possibly using cacheAsBitmap on the top ("intercept") sprite as well would change the behaviour.

I won't have a chance to play with that for a while but given that this bug could be critical for some apps, if anyone does figure something out please post here!

Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
Developer
Posts: 439
Registered: ‎10-25-2010
My Device: Not Specified

Re: Events not working as expected

[ Edited ]

I would strongly lean towards a bug in the QNX component set and not a runtime error.

 

For some reason, QNX decided to attach their MOUSE_DOWN listener for their lists, onto the stage, which means the list is always capturing down events that you don't want it to. Stage is sortof the one exception to the "overlay" rule, mouse events on stage are always fired, regardless of any sprites overtop of it. All other display objects respect the order of the display list, assuming mouseEnabled has not been set to false.

 

The list is probably catching the click event, via stage, and then killing it for some reason...

 

 

If you attach a down listener to your stage with priority=1, it should always fire first and give you a chance to kill propogation if you like.