I have a TwoWayScrollPane with morphs inside its scroller, a TransformMorph. When I scroll to the right, everything looks fine.
Call the "full window" the area onto which the "scroll window" provides a view. So when I scroll to the right, the full window is moved to the left.
The problem is that events are still going through to the full window. When I mouse down outside of the scroll window, but in the bounds of the full window, the click sometimes goes to a morph in the full window. When I drop an object, it goes to the full window. This happens even if I have other morphs that I've lifted to the top of the screen, morphs that themselves accept clicks and drops.
I have enabled drop and drag in the TransformMorph. The morphs within it are supposed to be draggable; the problem is that they are doing this even when they are outside of the scroll window.
Does anyone have any pointers on why this is happening? I'm using the tweaked classes I posted earlier.
One thing that I've wondered about is that I've stuck my morphs directly in the TransformMorph, rather than putting a container (perhaps a RectangleMorph or AlignmentMorph) in the TransformMorph, and then the other Morphs in the container.
The explorer on the World PasteUpMorph does not seem to show my submorphs directly, and all the bounds for the TwoWayScrollPane, its scroller, and the contained Morph's look reasonable.
I conclude that my mouseDown is not going to the TwoWayScrollPane or the TransformMorph, but that somehow the event mechanism knows where my morphs inside of it are (which means its aware of the coordinate transformation done by the TransformMorph) and is sending the mouse event direct to one of those "inside" morphs.
On Sun, May 29, 2005 at 10:55:55AM -0700, Ross Boylan wrote:
I have a TwoWayScrollPane with morphs inside its scroller, a TransformMorph. When I scroll to the right, everything looks fine.
Call the "full window" the area onto which the "scroll window" provides a view. So when I scroll to the right, the full window is moved to the left.
The problem is that events are still going through to the full window. When I mouse down outside of the scroll window, but in the bounds of the full window, the click sometimes goes to a morph in the full window. When I drop an object, it goes to the full window. This happens even if I have other morphs that I've lifted to the top of the screen, morphs that themselves accept clicks and drops.
[snip]
The immediate cause of the problem is that fullBounds of the TransformMorph cover the "full window." TransformMorph overrides the fullBounds method specifically to prevent this, but it caches the results. Apparently something else got to the cache. A check of mutators on the fullBounds instance variable reveals removeDropShadow, shadowPoint:, and privateFullBounds: as possible suspects.
MorphicEventDispatcher>>dispatchMouseDown:with: includes this at the top: "Try to get out quickly" globalPt _ anEvent cursorPoint. (aMorph fullBounds containsPoint: globalPt) ifFalse:[^#rejected].
Among the possible fixes are for TransformMorph to use a custom event dispatcher, for it to override rejectsEvent: (which currently does no geometry tests), tracking down all the other places that reset the fullBounds instance variable, or modifying fullBounds to avoid caching. But TransformMorph>>fullBounds already includes a note suggesting it shouldn't be there--which means the default fullBounds, which give the "full window" would apply and that further monkeying with fullBounds is probably not a good idea.
Seeking to avoid modifications to system classes (or whatever the Morphic classes in the image are considered) and the proliferation of new classes, I did the following hack instead
RBTwoWayScrollPane>>rejectsEvent: anEvent "my embedded scroller thinks it extends beyond this window" "this is a hack" ^(self outerBounds containsPoint: anEvent cursorPoint) not or: [super rejectsEvent: anEvent].
I conclude that my mouseDown is not going to the TwoWayScrollPane or the TransformMorph,
wrong. Because of the use of fullBounds in event dispatching, these morphs effectively occupied the "full window" and so got the events.
[snip]
Past experience indicates that roughly 5 minutes after I think I've finally got things working I discover a new problem, so we shall see...
Thanks for listening. Ross Boylan
P.S. These problems might indicate some code changes are appropriate somewhere in the Morphic system. I leave it to those more qualified to make such a decision. Perhaps the event dispatch should check outerBounds instead of fullBounds, though I take it the former will not include drop shadows and other decoration. This is all in a 3.6 image.
squeak-dev@lists.squeakfoundation.org