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.