"Raab, Andreas" wrote:

> Due to some legacy code I had to make sure only those morphs receive mouse
> up that are the current mouse focus. Since neither the dropped morph nor its
> recipient are the mouse focus, none of them will get the mouse up event [I
> actually wanted to dispatch the event that lead to the drop itself but it
> turned out that this raises even more legacy issues which I couldn't fix
> rapidly enough to make it work]. So the short answer is to make the dropped
> morph sensible to mouse up when it dropped:
> 
> MyMorph>>justDroppedInto: someMorph event: anEvent
>         super justDroppedInto: someMorph event: anEvent.
>         anEvent hand newMouseFocus: self.

Ah. I saw the following comment in justDroppedInto:event:

	This message is sent to a dropped morph after it has been dropped 
	on--and been accepted by--a drop-sensitive morph

and assumed that it meant that the morph being dropped on would have to
accept the morph. However, that won't work for me (as I said) because
the AttachmentPointMorphs should work with ANY Morph (including, say,
a RectangleMorph, which generally doesn't accept anything being dropped
onto it).

In fact, I'd like to suppress the entire drag'n'drop behavior if I could,
and just get a mouseUp.

I guess I could make the APMorph follow the Hand in its step method, and not
make it grabbed by the Hand. But that will require changing more code.

> BTW, the mouse over handler is completely unrelated to this entire issue. It
> only figures out what morphs are currently "under" the hand to generate
> appropriate mouse enter/leave events.

Yes, I was looking at that. I noticed that if you have Morphs A and B, and
A is below B, then if B is smaller than A and you move your mouse over the
stack, you get:

enter A
leave A
enter B
leave B
enter A
leave A

Now, I would have thought that when the mouse was over B it was also over A,
or is this not how it's supposed to work?

-- 
Ned Konz
currently: Stanwood, WA
email:     ned at bike-nomad.com
homepage:  http://bike-nomad.com