Hi, 
so now I know why I can get so many spurious enter/leave events. It’s really embarrassingly dumb…

When you are dragging a morph around and have the morph positioned at the event cursor point - ie not centred under it as you eventually want - then moving even moderately quickly can result in the cursor point being over the dragged morph. Which is not the canvas morph. So you’ve left the canvas morph; and you get a mouse leave event. D’oh! Then the fake-cursor-morph gets deleted, you are now over the canvas morph so you get a mouse enter event, and so on.

I worked this out eventually because I added the centring offset negated and so the fake-cursor was well out of the way and hardly any enter/leave events came in.  When I ‘corrected' the offset, everything was flashing madly as gazillions of enter/leaves flooded the place since the morph was directly under the cursor and thus always causing a leave event.

Thus my conclusion is that we can’t drag a morph around like this. Sigh.

It looks like adding some code to grid-step in HandMorph>position: is the only way to proceed now. 
I’m going to work on the assumption that only the temporary cursor needs to worry about it, though if people want the cursor in general to grid it wouldn’t be hard to expand that. I’m not hugely keen on messing with HandMorph since it is so central to the UI so I’ll stick with a couple of globals or properties for the gridding info for now.

One question for you all - if I added a subclass GriddingHandMorph, how tricky is it to swap the current hand around. Could I reasonably swap to a gridded hand when entering my canvas morph and back to an ordinary one on leave? Would it be saner to just swap to a gridded hand in my product image and leave it at that?

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: TVO: Type Various Obscenities