First of all, sorry for replaying a bit slowly. My week end was quite busy and I was not in front of my computer.
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
It is integrated in Roassal!
Thanks!
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.
Hum… This is a strange bug…
I do not quite understand what’s going on here. I have an error in
TRCompositeShape>>shapes
^ shapeAndOffsets collect: #first
Problem 3)
As we discussed in topic "[Roassal] TRCompositeShape not sending callbacks"
(
http://forum.world.st/Roassal-TRCompositeShape-not-sending-callbacks-td4814221.html), 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.
Sincerely, I am not convinced at all by TRCompositeShape, as it is implemented now.
For example, having a shapeAndOffsets variable is odd to me.
Apparently, you guys are having a deeper use of it than I do. You can easily make your own CompositeShape, and all in a modular fashion, without touching the core of either roassal or trachel.
I would like to help you on this, but I am not sure how.
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)?
I think this is because of the composite shape. A question: can a composite shape have a position that is different than its center? I think yes.
Cheers,
Alexandre