If you are receiving down events, then the view is almost certainly not set
to GONE or it is still animating.  The code for this part of dispatching in
ViewGroup is pretty simply, and just immediately skips any non-visible
views:

                       for (int i = childrenCount - 1; i >= 0; i--) {

                        final View child = children[i];

                        if ((child.mViewFlags & VISIBILITY_MASK) != VISIBLE

                                && child.getAnimation() == null) {

                            // Skip invisible child unless it is animating.

                            continue;

                        }

So be sure the view is actually gone, and that you haven't left an animation
in it.

On Mon, May 23, 2011 at 1:31 PM, Anm <[email protected]> wrote:

>
> This morning, I'm trying to animate the various state of a simple
> game.  I have a transparent cover ViewGroup with a start and other
> buttons.  When the user hits start, the entire cover animates away.
> At the end of the animation, I set the cover View to GONE which looks
> correct, but the start button is still grabbing touch events instead
> of the game's view.  I had to manually iterate over all the start
> button and other views within the cover to setClickable( false ) and
> setEnabled( false ) (not sure if both were really needed) before I
> started receiving my touch events again on the layers below the GONE
> ViewGroup.
>
>
>
> On May 23, 12:33 pm, Justin Anderson <[email protected]> wrote:
> > I have never run into this... What situations have you come across where
> > this happens?
> >
> > Thanks,
> > Justin Anderson
> > MagouyaWare Developerhttp://sites.google.com/site/magouyaware
> >
> >
> >
> >
> >
> >
> >
> > On Mon, May 23, 2011 at 1:13 PM, Anm <[email protected]>
> wrote:
> >
> > > This is something that I've run into a couple of times, and I'm just
> > > curious about the thought process behind such design, if intentional:
> >
> > > When a view has visibility GONE, it is still allowed to accept UI
> > > events.  This is especially strange in positional UI events like
> > > touch, where any positional state it likely an artifact of past/
> > > invalidated state.
> >
> > > My colleagues and I cannot come up with any scenario where this
> > > behavior would be desirable.  Quite the opposite, it would seem to be
> > > an easy way to limit the view tree traversal for event handling.
> >
> > > Any insight would be greatly appreciated.
> >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Android Developers" group.
> > > To post to this group, send email to
> [email protected]
> > > To unsubscribe from this group, send email to
> > > [email protected]
> > > For more options, visit this group at
> > >http://groups.google.com/group/android-developers?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
>



-- 
Dianne Hackborn
Android framework engineer
[email protected]

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails.  All such
questions should be posted on public forums, where I and others can see and
answer them.

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to