Hi Andrew,
This is one I bumped heads with a while back.
I tried things along the line you suggested and tied
myself in knots.
So I started with what I knew worked. Handles on
polygons and looked at what they used.
The #on:send: message is the best way I have found to
add behavior to morphs.
define a method in your inheritance chain (e.g.)
Morph>>initializeMyMove
self on: #mouseMove send: #moveThisWay to: self
; on: #mouseUp send: #stopThat to: self .
Then make methods
#moveThisWay and
#stopThat in your specific subclass to do what you
want.
Then make a sample of your morph and send it the
initializeMyMove message.
where circle understands what you mean by #moveThisWay
and #stopThat.
I found by experimenting that circle would not listen
to mouse move unless it was also listening to #mouseUp
or #mouseDown.
I also found I absolutely didn't need to write my own
low level stuff for the morphs.
-----
To stop the rectangle from moving you need to make it
"resist being picked up" from the red halo or tell it
to #beSticky programatically.
I also agree that if you can get away with using a
pasteup morph instead of the rectange thats a win. A
tip of the hat to Andreas who said it first.
-----
There are also tricks for making the gui feel
smoother. For my application I update my morphs
position from the
delta of the mouse move
desiredPosition := oldPosition + mouseMoveEnd -
mouseMoveStart + tug.
Where tug was a vector based on the signs of the
coordinates of (mousePosition - oldPosition).
finally you apply constraints to desiredPosition (e.g.
constrain to be within the owners bounds and what
results is the newPosition to which you move your
morph.
On mouse up I wanted to insure my morph wound up on a
grid intersection. So the final behavior was
essentially snap to grid.
Again for ideas look at the behavior of handles.
HTH,
Yours in service, --Jerome Peace
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Locked
