What is the difference between a.x = 100; a.y = 100 and a.move(100,100) ?

Question

Hi, everybody.

What is the difference between using

a.x = 100;
a.y = 100;

and

a.move(100,100);

in actionscript 3 / Flex ?

Best regards,
Artem

Answer 1

Just guessing (I don't know actionscript) but I would have thought that

a.x = 100;
a.y = 100;

would set a to be (100, 100), while

a.move(100,100);

would add (100,100) to the current value of a. However, in light of the accepted answer it appears it does the same. Though the following advice still holds:

Have you tried the latter for different initial values of a (0, 0), (100, 100), (23, 42) etc. and checked what happens?

If you're not sure about something test it out - you're not going break anything and it even getting it wrong first time can teach you something.

I did a quick search for some documentation, but wasn't able to turn anything up. I think your best bet is to generate some test examples to explore what each approach does.

Answer 2

In general: calling a method communicates what you're doing, just poking member variables doesn't.

As ChrisF said, there might also be a difference where poking moves to absolute coordinates, while the method call moves relative to the current position. I tried looking up a reference, but didn't find one.

Answer 3

What is a? If we knew what 'a' is then it would make it simpler to answer. The a.x or a.y would normaly specify the coordinates for the top left hand corner of the object (say Button) in its parent (say Canvas).

If 'a' was a Button then setting .x and .y or setting move(x, y) will do the same thing.

Check the docs out 'Moves the component to a specified position within its parent. Calling this method is exactly the same as setting the component's x and y properties. '

http://livedocs.adobe.com/flex/3/langref/index.html, it under UIComponent.

Answer 4

ActionScript properties can in fact, be backed by methods - so called getter/setter pairs. So when you set the property a.x = 100, there's quite likely code that is executing to deal with the implications of that property change. (Not knowing what type a is here, it's not possible to know for sure - indeed, it's never possible to know in general, and you shouldn't assume that you do)

Be careful about one thing here: calling a single method such as a.move(x,y) could be quite different from calling two the two separate setter methods behind a.x = q and a.y = r It all depends on how the class you're using has been implemented. For this reason, many Flex framework classes (all?) use the invalidateProperties() ... commitProperties() pattern to ensure that all property changes are coordinated through a single control point.

Answer 5

Here is a case when it's better to use move :

If you are overriding the updateDisplayList() method in a custom component, you should call the move() method rather than setting the x and y properties.The difference is that the move() method changes the location of the component and then dispatches a move event when you call the method, while setting the x and y properties changes the location of the component and dispatches the event on the next screen refresh.

Answer 6

[WINDOWS_USER_PROFILE_PATH]\Local Settings\Application Data\Adobe\Flash[version]\en\Configuration\Classes

Always look here to know exactly. If you mean UIControl, then look at [PATH_ABOVE]\mx\core\UIObject.as

And you'll see the difference:

function move(x:Number, y:Number, noEvent:Boolean):Void
{
 //trace("UIObject.move " + this + " -> (" + x + ", " + y + ")");
 var oldX:Number = _x;
   var oldY:Number = _y;

 _x = x;
 _y = y;

 if (noEvent != true)
 {
  dispatchEvent({type:"move", oldX:oldX, oldY:oldY});
 }
}

So, the correct answer is: After assigning new coordinates this method dispatches a 'move' event, supplied by old coordinates. That's all.

PS: if you use another flash compiler - just find it's class definitions somewhere on your machine...