GreenSock

Again, this is a bug in Flex, not TransformManager. I'd recommend avoiding borders and instead, apply them manually with a Shape or something. You'd get the same effect visually, but without the bug.

var myManager:TransformManager = new TransformManager({targetObjects:[mc1, mc2, mc3], scaleFromCenter:true}); myManager.selectItem(mc1); //or just let the user select what they want by clicking var bounds:Rectangle = myManager.getSelectionBounds(); Does that help? And just for clarity, getSelectionBounds() has nothing to do with the bounds that you apply to the TransformManager to ensure that the objects stay within a certain area. getSelectionBounds() just returns a rectangle that defines the coordinates of the actual selection box at the time.

Not sure why everything would disappear, but your code looks like it would cause a feedback loop because you're listening for a selection event, and when that happens, you're selecting something which fires a selection event which calls your handler which changes the selection which fires a selection event, and so on. Why would you change the selection inside your handler for selection changes?

Keep in mind that TransformManager accommodates multiple selections, so don't assume that the event.items would only contain one item. Regarding the getSelectionBounds(), it does indeed pertain to the TransformManager instance, and just like the getBounds() method, it reports the bounding box as though you drew a rectangle around the selection box. So if it is rotated, the width would be wider than if it wasn't rotated. You could use getUnrotatedSelectionWidth() if you need the...um...unrotated selection width If you want to get the selected items' width, you could loop through the event.items Array and get each one's width or targetObject.width property. Does that help?

Yep, except I think you had a typo - it should be managerOne.addItem() and managerTwo.addItem(), not mgr.addItem() for both.

I'm not sure exactly how you want to store them, but here's an example that creates a "data" array with an object for each targetObject, containing all the matrix data (a, b, c, d, tx, and ty): var targets:Array = myManager.targetObjects; var m:Matrix; var data:Array = []; for (var i:int = 0; i m = targets[i].transform.matrix; data.push({a:m.a, b:m.b, c:m.c, d:m.d, tx:m.tx, ty:m.ty}); }

bounds are meant to apply to TransformManagers, so if you want to have different bounds for your various items, you'd need to create multiple TransformManager instances (one for each).

I'm not familiar with ImageSnapshot.captureImage(), but sure, it should be pretty easy to loop through the TransformManager's targetObjects Array and record their transform.matrix values (a, b, c, d, tx, and ty) so that you could store those in an XML file (or wherever) and re-apply them later.

AS2 or AS3?

Yeah, sorry, but I'm not much of a PV3D guy so I couldn't tell you what the problem is. I suspect that a Plane doesn't extend DisplayObject or it overrides the colorTransform stuff internally. Any PV3D guys want to chime in?

You're passing the wrong kind of value to tint. BAD: tint:{color:0xFFFFFF, tintAmount:0.5} GOOD: tint:0xFFFFFF If you need to control the amount of tint, just use the colorTransform plugin, like: import com.greensock.*; import com.greensock.plugins.*; TweenPlugin.activate([ColorTransformPlugin]); TweenLite.to(event.currentTarget, 1, {colorTransform:{tint:0xFFFFFF, tintAmount:0.5} });

I'd need to see an example of what you're talking about - could you post an example (do not include the TransformManager classes please). The simpler the better.

Just keep in mind the following: 1) All items that a TransformManager manages must share the same parent (as indicated in all the documentation and on the blog) 2) You can get the TransformItem associated with any DisplayObject like var item:TransformItem = myManager.getItem(myObject); 3) When dynamically loading content, make sure that you either wait until it has fully loaded and instantiated BEFORE adding it to the TransformManager or just call update() on the TransformItem after it has loaded and instantiated. Does that help? (not sure I understood your question)

Could you send me a sample Flex project (or FLA) that demonstrates the issue? Are you using the latest version? Keep in mind that if you edit the contents/scale/rotation of the object without going through TransformManager, you need to make sure you call update() on the associated TransformItem so that it refreshes.

I believe I found the problem. It only showed up if you dragged far enough in the opposite direction. Please download the latest version from the link I sent you and let me know if that works well for you. Sorry for the inconvenience.

You have several options: 1) Do the math yourself before you put the delays into the tweens. Kinda like: var duration:Number = 0; var delay:Number = Math.random(); duration = Math.max(duration, delay + time); TweenLite.to(mc1, time, {x: num, delay: delay }); delay = Math.random(); duration = Math.max(duration, delay + time); TweenLite.to(mc2, time, {x: num, delay: delay }); ... TweenLite.to(mc5, duration, {x: num }); 2) Just use the new TimelineLite class in v11, like: var myTimeline:TimelineLite = new TimelineLite(); myTimeline.appendMultiple( [TweenLite.to(mc1, time, {x: num, delay: Math.random()}), TweenLite.to(mc2, time, {x: num, delay: Math.random()}), TweenLite.to(mc3, time, {x: num, delay: Math.random()}), TweenLite.to(mc4, time, {x: num, delay: Math.random()})]); myTimeline.insert( TweenLite.to(mc5, myTimeline.duration, {x: num}), 0); So basically, you can dump your tweens into a TimelineLite and check its "duration" property. Get v11 at http://blog.greensock.com/v11beta/

I just tested it and it seemed to work perfectly for me. Could you send me a sample FLA or Flex project that demonstrates the issue? Just private message me.

Did you apply the scale constraints so that the minimum scaleX/scaleY are 0? That would prevent them from going negative.

I've rotated an object over 100 times in a row (without releasing the mouse) and cannot for the life of me get it to break. And nobody else has reported anything like that, so I'm wondering if maybe there's something else going on in your code? If you could send me an example, it would definitely help with the troubleshooting.

Nope, I just meant you should store the Matrix values themselves. Those control all the aspects of the scaleX/scaleY/width/height/rotation/x/y anyway. Like: var matrix:Matrix = myObject.transform.matrix; //store these values... var a:Number = matrix.a; var b:Number = matrix.b; var c:Number = matrix.c; var d:Number = matrix.d; var tx:Number = matrix.tx; var ty:Number = matrix.ty; //then later, to re-apply them... myObject.transform.matrix = new Matrix(a, b, c, d, tx, ty);

I'd recommend simply storing the transform.matrix values instead of scaleX/scaleY/width/height/rotation. It's cleaner that way. If you must store the width/height, you could use textField.getBounds(textField).

Hm. Never heard of that before. Can't imagine why it would happen either. If you can send me a file that reproduces the problem or instructions as to how to make it happen, it'd be great. Otherwise I suspect it's something else in the app. I know you said you couldn't reproduce it either, so that may leave us both scratching our heads.

Simple3D is pretty much completely unnecessary if you're plublishing to Flash Player 10 because Flash Player 10 natively supports rotationX, rotationY, and rotationZ, along with x, y, and z properties. Is there a reason you wanted to use Simple3D in FP10?

Were you expecting LiquidWrapper to allow all the extra boxes to violate its boundaries? I'm a little confused about what you believe isn't working. As the documentation indicates, LiquidWrapper forces its contents to fit within its boundaries, and it always scales them proportionally. So when your b.swf adds a bunch of boxes vertically, it makes b.swf much taller than it was before, so LiquidWrapper scales it down proportionally to fit within itself. That makes everything smaller in b.swf including the text. As far as I can tell, LiquidWrapper is doing exactly what it's supposed to (unless I'm missing something which is entirely possible - I'm a little sleep deprived).

Sorry for the confusion - I should have made a note in the ASDocs that the bounds of TransformItems should match the bounds of their TransformManager. I'll make that note and post with the next rev. Allowing each TransformItem to have different bounds would degrade performance because on each MOUSE_MOVE, it would have to check for violations of bounds on each selected item. Plus I'd definitely consider it an edge case - when a developer imposes bounds it's virtually always on a TransformManager basis, not TransformItem. You could create a TransformManager instance for each set of bounds if you prefer. Thanks for pointing out the discrepancy - I'll make the note in the docs and remove the "bounds" property from the TransformItem ASdocs.