skiller

Sorry for being a pain in the arse, but I'd like to suggest a few additions. While inspecting the code and the newly added cropping features, it turns out that I've already been down that road (which I don't mean in a diminishing way, your efforts are well appreciated!). It turned out, though, that there are a few requirements that still need to be met, especially that the crop selection must not exceed the image's bounds – something I found impossible to achieve without drilling holes into the TransformManager/TransformItem (which - per se - is okay and covered by the license, but it would still feel more natural as a TM/TI functionality). I assume the TransformManager's bounds are thought to restrict the movement of managed items within the limits of a "canvas", hence it merely accepts an unrotated rectangle relative to the TransformManager's space as bounds parameter. So what I have to do is monkey patch the TransformItem in a way that I can check if it is inside of the image bounds first before I allow it to move its handles – which results in a very undesired dependency and strong coupling between the TransformItem and the target object. How about enhancing the TransformManager in a way that it respects rotated retangles as well? Or even better: keep the current TransformManager "canvas" bounds and allow for TransformItems to have their own boundaries? That would make the TransformManager/TransformItem a black box again. So here's the desired enhancement/workflow: A TransformItem should accept an arbitrary UIComponent as a bounds parameter of its own, using its bounds and rotation to restrict its own and its handles' movement. So basically, I have a Flex component that is equivalent to the image's clip mask (undesired image portions are clipped through Flex's own clipping mechanism, i.e. clipAndEnableScrolling). When in crop mode, the image will stay in place, rotation is locked and scaling is forbidden. I have no problem with setting the component's image position back to its fixed position after it has been moved by the TransformManager/TransformItem – that's the easy part. The tricky part is restricting the item to the confines of the image, since the crop mask should never exceed the image (which it does with the TransformManager/TransformItem/Crop classes in their current form). Let me know what you think. Best regards Constantin

Hi there, I had written an elaborate forum post about how I wished the cropping would work which I couldn't post because the forum wasn't reachable, but it turned out you did it anyway. Thanks again for your efforts. I just wanted to assure you that your efforts are very well valued, and the TransformManager is a great piece of code, and with the latest addition it has become even better. Best regards Constantin

Thanks, great! You're a Wiz. A little different than I would've envisioned, but works like a charm. And to have this functionality *within* the TransformManager definitely reduces coupling. Best regards Constantin

Thanks for the reply. The cropping should not be that hard, especially in Flex, where you can quite easily use Flex's own cropping mechanisms in its components (so there's no need to juggle masks like in an earlier approach I've tried). I'm basically switching from normal scale mode to width/height scale mode when the crop mode is activated because I don't want any scaling to occur (maybe I should try to simply lock scaling…), but I find it peculiarly hard to track and translate the right set of modifications, and when switching back to normal scale mode there are unwanted transform matrix modifications that ruin my calculations by occuring too early. But I suspect I still haven't grasped the intricacies of TM to their full extent. Initially, the TransformManager was suggested to make the scaling and cropping easy. Now I find myself sifting through the code, trying to grasp what happens when (and why), which calculations to stop and which modifications to allow. And, to be honest, the intensive use of generic objects doesn't make debugging easier. I'd rather have Value objects that I can subclass and put breakpoints into. Right now I've resorted to monkey patching the TransformManager, but is definitely not pretty. Maybe we can find a solution together, and if it suits the TransformManager well we could look for ways to blend that functionality into it. Looking forward to your suggestions… Best regards Constantin

Hi there, I've spent a good part of the last few weeks trying to use the TransformManager for an application that not only scales, rotates, and moves images, but also crops them. I find the moving, rotating and scaling part compellingly easy to achieve with the TransformManager, but it doesn't seem to be suitable for moving, rotating and scaling cropmasks, too. The requirements: [*:2a6p5l9k] There is a layer with an arbitrary number of images and text elements (RichText) that are created on the fly by the user[*:2a6p5l9k] above that layer there's another layer that partially obscures the image/text layer (a kind of mask/template – but not a clip mask, since the parts "masked out" still "shine through" the mask)[*:2a6p5l9k] yet on top of that is a layer that contains control elements for the images/textitems that must not be obscured by the mask/template layer[*:2a6p5l9k] images are to be scaled, rotated, moved and cropped on the fly[*:2a6p5l9k] it should be possible to grab the items even if they're mostly obscured by the template/mask layer --> the handles and borders of selected items must appear "above" the template, even if the corresponding image is "below" the template/mask[*:2a6p5l9k] images must be scaleable/croppable in-place even if they're mostly "under" the template/mask The setup: [*:2a6p5l9k] The TransformManager sits atop the template layer and governs placeholder elements ("proxies"), which are created along with each text item/image and added to the TM[*:2a6p5l9k] the TransformItems relate to the transparent proxies, changes in dimensions, position, and scale are updated to the corresponding image/text (through Flex's commitProperties/invalidateDisplayList mechanisms)[*:2a6p5l9k] image items are their own clipmasks, i.e. masking and clipping is achieved through negative positioning of the image inside the image box element[*:2a6p5l9k] TransformManager operates in two modes: SCALE_NORMAL has image scale, move, and rotate as a whole, SCALE_WIDTH_AND_HEIGHT should keep the image in place, preserve/freeze the scaling, lock rotation, and only move the crop mask within the boundaries of the image The problems: [*:2a6p5l9k] TransformManager removes and adds TransformItems when switching their scale mode between scaling and cropping, resulting in the current item to be forced out of its ongoing modification[*:2a6p5l9k] the crop mask should be confined to the image, i.e. "scaling" and moving the image mask must not lead to a situation where part of the mask are outside of the image --> the TransformManagers bounding box remains unrotated, leading to undesired mask bleeding for rotated images and actually rendering the TM's bounds mechanism unusable[*:2a6p5l9k] TransformManager uses x/y + width/height as well as transform matrices to manipulate the TransformItems, making it very hard to simply "listen" to changes in the desired properties (sometimes dragging handles results only in a modified transform matrix, Matrix doesn't implement IEventDispatcher, though, leaving you with the only option to listen for frame events) The possible solutions: [*:2a6p5l9k]TransformManager should support bounding boxes that are not just unrotated rectangles, allowing for easy crop mask confinement inside of an image's area[*:2a6p5l9k]TransformManager/TransformItem should emit events when the transform matrix changes[*:2a6p5l9k]maybe even a full-fledged cropping mechanism out of the box? *wink wink wink* Thoughts are welcome, because I'm really stuck here. A colleague talked me into buying this pile of… monolithic code that I'm having a really hard time with. Hey, it costs three hundred bucks – I expect it to behave well then. Get me right, the TransformManager goes great lengths in the right direction, but it stops short. Or do you think it's not suitable for that purpose and I should get a refund? Best regards Constantin