IIRC, one of the reasons we don’t use Sprite.width/height is because if you use masks to clip content so the visuals only cover a particular dimension, the Sprite.width/height still show the bounds for unclipped content.
On 5/9/10 12:59 AM, "[email protected]" <[email protected]> wrote: Well, since flex is based on bindings and there's no way to "watch" the transformations made through .transform property of display objects, I would expect this behavior. In fact I do use transform.matrix instead of "normal" x, y, width, hight and so on if I want to skip flex validation routines, well, that's if I must do something more complex then simple positioning stuff, especially if it has to do with animation. To be honest I think that the idea of layout manager wasn't the best way to approach gui with complex animation / need for often rendering updates... If anything, I'd opt for BeginUpdate() / EndUpdate() functionality that you have to call when it's required, without trying to guess the "optimal" timing when to update things and what must be updated. What also seems odd is that in flex it doesn't follow the flash "native" idea of how display object transformation is handles. That is while in flash all those x, y, width, height stuff are the setters / getters of a single transform matrix, in flex those may be a bunch of unrelated properties. Given this situation, I wouldn't be surprised some would fall out of synch. In the imaginary world :), where I would have to redesign how it's done in flex, I think I'd go for something more like: <UIComponent> <Transform x="{expresion}" y="{expression}" ... /> </UIComponent> So that there would be only one way to manipulate display object transformation. If there are more then one, it is just asking for an error. Best. Oleg -- Alex Harui Flex SDK Team Adobe System, Inc. http://blogs.adobe.com/aharui
