[Moose-dev] Re: Roassal TRCompositeShape regression

Hi once again I'd like to bring here together all current problems of composite shapes, add one more and propose one fix. Problem 1) This topic was started because remove callbacks got triggered from same shape multiple times by single event. I think I fixed this problem. And I did few more things to TRCompositeShape while I was at it. I fixed exactly same problem with translation callbacks, I modified composite shape callback test to test this case with removing, and I added and used shapesDo: and firstShape methods to simplify code and make it faster - calling Collection>>#collect:thenDo: is faster than (collect:)do:, because is does not create temporary collection in the middle of it. mcz: http://www.mediafire.com/download/lh37m9n0rq21e7n/Trachel-bliznjan.275.zip Problem 2) Unfortunately, in the meantime, I found much nastier bug, which is not so common to trigger, but it causes infinite loop and it happens in our DynaCASE app. It happens only if: We have a composite shape, canvas of this composite shape is not set (is nil), and then we add TRTranslationCallback to that shape - callback which gets encompassingRectangle of this shape in its block. If canvas is nil, method encompassingRectangle sends (for some reason unclear to me) positionShapesAfterBeingAdded, which translates subshapes, which triggers translation callback, which sends encompassingRectangle, which sends positionShapesAfterBeingAdded etc... Same problem happens by calling many methods which then call encompassingRectanhle, like center, position, extent, height and width. Example code: | shape process | shape := (RTBox new + RTBox new) element. shape addCallback: (TRTranslationCallback block: [shape encompassingRectangle]). process := [shape translateTo: 100@100] fork. (Delay forMilliseconds: 300) wait. process suspend; debug. Problem 3) As we discussed in topic "[Roassal] TRCompositeShape not sending callbacks" ( http://forum.world.st/Roassal-TRCompositeShape-not-sending-callbacks-td4814… ), there is a problem if I use simple addCallback: for translation or extent callbacks, because this way it triggers only when first subshape is changed, but after that, the rest of subshapes get changed, but no callback is triggered anymore. You proposed method addCallbackToAllShapes:, but it would require to make nasty exceptions and type checking for composite shapes in multiple places in our code, because TRRemoveCallbacks have to be triggered only once per composite shape (which seems to be opposite of translation and extent callbacks). Only possible solution that occurs to me is to edit addCallback: just for our need in subclass of RTCompositeShape, or use mentioned replacable blocks for that in TRCompositeShape. Question 1 (maybe Problem 4?)) And to finish this, I have one question. What is and/or should be difference between TRShape>>#position and TRShape>>#center? In case of RTElement, it is explicitely the same, but what about here, where it sometimes is and sometimes isn't the same, especially with composite shapes (but not only them)? Jan Blizničenko -- View this message in context: http://forum.world.st/Roassal-TRCompositeShape-regression-tp4816726p4820464… Sent from the Moose mailing list archive at Nabble.com.