1

I have a grid of many 10x10 pixel squares separated only by a pixel line. When the user rolls over the sprite, it grows, animating to about 4 times its size--to around 40x40 pixels. The sprite stays large while the mouse is over the sprite, but if the user wants to rollover the neighboring sprite it is obscured by this sprite and its larger size.

Is it possible to shrink the size of the hit area so that even though the sprite grows in size the mouse can still access or trigger the neighboring sprites underneath--to the right, left, top, bottom? I thought about using Mouse_move, but wasn't sure if that would fire off too many events.

I read the following posts. However, my hitArea needs to be the same size or just slightly larger than the original 10x10 pixel sprite. I've had little success.

Not sure if this matters: I'm working with an ActionsScript class within a Flex project. The main class file is mxml.

Routing Mouse Events through a Sprite in Actionscript 3

AS3: defining hit area

public function onRollOver(event:MouseEvent):void
{  
    //do a bunch of stuff
    timerUp.start();
    timerUp.addEventListener(TimerEvent.TIMER, growSquare);     
}

private function growSquare(e:TimerEvent):void
{
    var maxSize:Number = 40;    
    if (currSprite.width < maxSize) {
        currSprite.width++;
        currSprite.height++;
        if (currSprite.width > maxSize) { 
        currSprite.width = maxSize;
        currSprite.height = maxSize;
        }
        e.updateAfterEvent();   
        } else {
          timerUp.stop();
        }   
  }


    /////////Hit Area Code - From Square Object //////////////////

        var vHeight:Number = 10;
        var vWidth:Number = 10;
        var square:Sprite = new Sprite();   
        square.graphics.beginFill(0x000000); 
        square.graphics.drawRect(0, 0, vWidth, vHeight);
        square.graphics.drawRect(-vWidth/2, -vHeight/2, vWidth, vHeight);
        square.graphics.endFill();

       // try to decrease the hit area, or keep it at the original size
        const hitArea:Sprite = new Sprite()
        hitArea.graphics.beginFill( 0xFFFFFF );
        hitArea.graphics.drawRect(-vWidth/2, -vHeight/2, vWidth, vHeight);
        hitArea.mouseEnabled = false;
        hitArea.visible = false;
        hitArea.x = square.x
        hitArea.y = square.y
        square.hitArea = hitArea;
        addChild( square );
        addChild( hitArea );
Community
  • 1
  • 1
cin13
  • 15
  • 4
  • Also, the currentSprite is the one rolled over. It has been moved to the top of the display list using setChildIndex... – cin13 Dec 17 '11 at 07:43

1 Answers1

2

You could split your sprite into two subsprites: one for the hit area and one for the drawing. Something like that:

public class GridBox extends Sprite
{
    public var hitAreaSprite:Sprite;
    public var drawingSprite:Sprite;

    public function GridBox()
    {
        hitAreaSprite = new Sprite();
        // Draw a 10x10 pixel box in hitAreaSprite, add event listeners, etc.

        drawingSprite = new Sprite();
        // Disable mouse input for drawingSprite here.

        addChild(hitAreaSprite);
        addChild(drawingSprite);
    }
}

...

var yourSprite:GridBox = new GridBox();

Then make yourSprite.hitAreaSprite to be 10x10 pixels and add your mouse listener events to it. yourSprite.drawingSprite must contain all the graphics elements and drawings. Set its mouseChildren and mouseEnabled properties to false.

Then when the sprite is supposed to grow, don't directly change yourSprite.width, but instead change yourSprite.drawingSprite.width. Since the mouse is not enabled for this sub-sprite, and the hitAreaSprite is not moving, the sprites below will still receive mouse events.

laurent
  • 88,262
  • 77
  • 290
  • 428
  • This sounds promising. But just to clarify, "YourSprite" is another object or class, and not an actual Sprite class. The "YourSprite" object has two sprites inside of it, is that right? I am going to try this and will comment soon. – cin13 Dec 17 '11 at 17:38
  • I added an edit showing how `yourSprite` could be implemented. It makes lots of sense to have the container class be a `Sprite`, so you can take advantage of the hierarchy of the display list. –  Dec 17 '11 at 20:44
  • Thanks very much both of you.. Yes, this is what I did also. I made a HitSprite as a separate class. The only thing is that on mouseEvents, since the events are attached to the hitAreaSprite, to change the size of the drawing sprite onRollover, I had to access it this way: **(event.currentTarget.parent).drawingSprite.width** Do we actually need the build-in sprite.hitArea property in this case? It sees like we don't since we are attaching mouseEvents to the hitAreaSprite. – cin13 Dec 17 '11 at 22:16
  • in other words, not sure what function **sprite.hitArea = sprite** serves for this case – cin13 Dec 17 '11 at 22:22