TransformGestureEvent misbehaving when zooming over child objects

[AuntieChristo]

I'm building an iPad app that has a few objects that have mouse/touch interaction and an overall zoom gesture on the stage (which zooms a placeholder with these other object added as children - so that all the objects zoom together).

All works well if I 'two finger' zoom on a clear area of the stage but if this action occurs over any of the children the placeholder zoom goes crazy! It's fixed by adding placeHolder.mouseChildren = false; - but then the interaction of the children can't be accessed?

I've also tried to add / reinstate the mouseChildren bool as follows:

if (event.phase==GesturePhase.BEGIN || event.phase==GesturePhase.UPDATE) {

  placeHolder.mouseChildren = false;

} else if (event.phase==GesturePhase.END) {

  placeHolder.mouseChildren = true;

}

...but it seems the event is already captured on the child object as the zoom misbehaves once again (event though the children do not have any TransformGestureEvent.GESTURE_ZOOM events added).

Has anyone else run else run into this problem and can offer a helping hand?

Many thanks in advance!

AC

[sinious]

Zooming can't go on forever. Perhaps a timer event to fire off the mouseChildren=true?

[AuntieChristo]

I'm not sure what you mean there - although perhaps I wasn't clear in the first place.

I dont want to zoom into the child objects - they have their own CLICK event listeners (which is why I can't disable the mouse actions on them).

They will zoom along with the placeHolder item as they're children of that object - but only the placeHolder has the TransformGestureEvent.GESTURE_ZOOM event - yet the ZOOM event seems to interact with these pesky children - even before I can catch it and handle it with the event.phase==GesturePhase.BEGIN.

I've tried adding the zoom event to the stage as well but the results are the same.

[sinious]

You're trying to scale a clip that contains other clips while somehow the children clips aren't affected. You're in the 1% margin of the time that someone wants that to happen.

It's math time. You're going to need to run a calculation on the scale of the outer clip and reduce the size of the child clips proportionately as well as re-align them if needed.

[AuntieChristo]

It's working in that respect - I've put the placeHolder there so that when that zooms - all it's children zoom accordingly (any transform to the holder will apply to it's children) - this is how I need it to behave. My problem is that when the zoom gesture is applied over one of the children - the holder zoom works in an errant manner - even though none of the children have a zoom event added to them.

There simply seems to be something that's throwing the zooming on the placeHolder out when the gesture occurs over a child.

Thanks for your responses tho - I'll get some code together so I can explain a little better...

[sinious]

Your children are capable of receiving (stealing) events. So when you roll over them you're now triggering another event.

For example, if you made a background for your whole outer clip and then applied the handler to that, all the images would be on top. Therefore anytime you roll over (touch) one of the pictures the event for the picture will fire off.

It's a catch 22 that I often use a little class I wrote called "Intent". When the user touches the screen I don't "do" anything until they tell me what they "intend" on doing. If they move their fingers I know they want to move something. If they touch it and let go briefly, I know that's probably a click "intent". It's how I allow large container clips to be dragged that contain children that can also be clicked. If you don't click and move the mouse (or a finger) a certain distance I consider it a click. Then I'd zoom in on the picture clicked. However if you touch and move your fingers, I'll do something else like drag or zoom, based on what you're doing.

Toss some trace()s up on the methods invoked when you sense for zoom and also on the image clips. I think you'll find your image clips are firing off and that's when you lose the zoom.

[AuntieChristo]

I think you're right - I've had various different results when using the event.stopImmediatePropagation() on some of the children's events so it's getting closer.

I like your idea of this 'intent' class - I think i'll take that approach!

Many thanks for all your input!

[sinious]

Some components can give you what you want like the scroller components (hopefully you're using Flash Builder or are using the latest Flex SDK for Spark components). Things like scrollers and Lists all use the same type of approach (I don't know how they do it but it's built in). Like on a list if you drag it the list will scroll but if you click an item it will select that item in the list. Same basic idea. "Do nothing on click, wait to figure out intent, handle it".

Let me know if you have any questions. I made that system wayyyyy back in AS2 before spark ever existed.

[AuntieChristo]

Hi again,

I've managed to overcome the problem without having to go down this 'Intent' route - almost by accident as it happens..!

I needed the zooming to work more intuitively (such as Xcode can deliver) - where you can zoom/pan & rotate in one 'gesture'.

The AS3 TransformGestureEvents can zoom & rotate at the same time but not pan (within the same gesture event) - which is far from ideal.

It was a slightly long winded way around but using the TouchEvent I've managed to get exactly this pan/zoom/rotate working in sync - (by calculating the average x/y differences between two 'touches', the distance between these points and the angle between them) and for some reason the problems I was having with the children's event have disappeared!?! I'm not entirely sure why - but I'm not complaining!

Many thanks once again - the 'Intent' class is certainly something I'll employ in the future!

[sinious]

No the intent is for the past. I was just offering past experience. I'm glad you figured it out in a modern way. Stick to that .