Adobe AIR Development

[PsykoJ]

What happened was I created a rectangle Sprite object.

I also added mouse events to it so that when I hover or click on it, it would change colors.

[ i used block.addEventListener(MouseEvent.MOUSE_DOWN, mouseClick); ]

The problem is, there seems to be an invisible event block outside the intended block that I added the mouse event to.

So when i click the green block its supposed to turn white, but it seems that the event block is larger than the green block.  When i also click somewhere near it.. it also changes to white.

I found this very strange.

This only happens in the simulator and it DOES NOT happen when I run it as a desktop application.

Anyone else have the same problem? or know a solution to this problem?

[red dot is where i click and green box changes to white]

[jtegen]

You might need to post your code to give a better answer.  Mouse events in Sprites respond by what is drawn in them, so I am interested in how you are drawing in that container.

Also, is the blue background your main application Sprite?

Additonally, if you're responding to a mouse click vs. a mouse down, I would listen to MouseEvent.CLICK instead of MouseEvent.MOUSE_DOWN, which is "typically" used at the start of a drag.

[PsykoJ]

Thanks for the quick reply.

Code is.

 var blockprite = new Sprite();

 block.graphics.beginFill(0x33cc33);

 block.graphics.drawRect(200, 200, 40, 40);

 block.graphics.endFill();

 block.addEventListener(MouseEvent.CLICK, mouseClick);

 addChild(block);

 public function mouseClick(e:Event):void

 {

 var blockprite = new Sprite();

 block.graphics.beginFill(0xFFFFFF);

 block.graphics.drawRect(200, 200, 40, 40);

 block.graphics.endFill();

 addChild(block);

 }

The mouse event could be anything actually,  i tried mouse down, mouse over, mouse up.. they all have the same issue.

And the background is not a sprite,  the background is just the background color.

 [SWF(width="1024", height="600", backgroundColor="#0033FF", frameRate="30")]

[jtegen]

Your main application should be extending a Sprite, which is that blue color background.

The code the way it is will continue to add sprites to the display list instead of just changing the color of the sprite you want to change.  So some basic code suggestions:

Create a new class like "block" that extends Sprite:

// pseudo code

public class box extends Sprite
{
  public var color : uint = 0xFF0000;
  public var size  : int = 200;

  ///////////////////////////////////////////////////
  public function box()
  {
    super();
    this.draw();
    this.addEventListener( MouseEvent.CLICK, ChangeColor );
  }

  ///////////////////////////////////////////////////////
  public function draw() : void
  {
    this.graphics.clear();
    this.graphics.beginFill( this.color );
    this.graphics.drawRect( 0,0, this.size, this.size );
    this.graphics.endFill();
  }

  //////////////////////////////////////////////////////
  private function ChangeColor( event : Event ) : void
  {
    if( this.color == 0xFF0000 )
    {
      this.color = 0x00FF00; // green
    }
    else
    {
      this.color = 0xFF0000;
    }
    this.draw();
  }
}

Then in the main code:

public class MyApp extends Sprite
{
    public function MyApp()
    {
      super();
      // show stage
      var mybox : box = new box();
      mybox.x = 40;
      mybox.y = 40;
      this.addChild( mybox );
    }
}

This should work in theory.  Not near a computer that has FB4, so this is on the fly but should give you some insight of what might be wrong.  If not, please let me know and I will try better.

[PsykoJ]

Unfortunately...

My main does extend sprite, and I also tried making a block class which also extends sprite.

Originally thats what i did, and i couldn't figure out the problem.  So i simplified it and put everything in my main.  

Just a reminder that it this problem does not exist when i run it as a desktop application. ONLY in simulator.

[taylortbb]

This discussion is also occuring over at http://supportforums.blackberry.com/t5/Tablet-OS-SDK-for-Adobe-AIR/Selecting-a-button-without-clicki... , and there's some useful info there about hitArea for Sprites. I also speculated it's a feature to make touchscreen input easier.

[jtegen]

Is the box changing colors or is the problem that near touches are changing the color as taylortbb suggests?

[PsykoJ]

i think taylor may be right in the analysis... im trying to do more research on the hitarea..

the box is supposed to change color when you click on it but if you click near it, it also does the same...

its like clicking on a button without clicking on it ...

if it was intentional,  wouldnt it conflict with things directly beside each other?

[jtegen]

Welcome to the world of touch screens.  Like to hear your result on the hit area here or on the other thread.  My guess the Z order of how the items are added to the display list will determine who got clicked for any near or overlapping items.  Touch screen controls need to some distance between them nor is a touch screen device good for "precision" work.

[taylortbb]

---

PsykoJ wrote:

if it was intentional,  wouldnt it conflict with things directly beside each other?

---

My guess is that there's some logic in there to determine what button the user is closest to. On my Torch on the homescreen I can tap above the "tray" title quite a ways as there's no active buttons for a few centimeters. Being a full centimeter off however doesn't work on dialogs with their close together buttons.