> moof of the day,
>
> Attatched to this file is a tiny stack that represents the problem I'm
> having dragging multiple objects. The project requires that if 1 or
> more buttons happen to intersect a grc then not only does the selected
> button have to move but also the other buttons which were found to
> intersect the grc. The idea behind this is to simulate a film reel in
> which the operator can drag and drop film strips (the buttons) onto a
> film reel (the grc), but since a reel is a single entity (in real life)
> then all the film strips (the buttons) within the reel (the grc) must
> move in succession.
>
> Kudos to anyone that can solve this.
The first thing that jumps out at me from this description (and the
stack) is if you get this working as you plan, how would you change
the relative spacing of the objects after they've been placed on the
track? Drag them off and then back on? That could get tricky...
If what you're really trying to implement is some sort of auto-scroll
feature, why not just use a scrollbar and set the loc of all the
buttons in the "reel" in a scrollbarDrag message?
The actual moving of multiple buttons should be pretty easy, and uses
the same algorithm as is used for moving a single button. Instead of
storing the original x, y coordinate into individual variables, this
would be a good use of an array.
So you'd change:
put item 1 of the mouseLoc - item 1 of the loc of the target into moveX
to:
put item 1 of the mouseLoc - item 1 of the loc of btn x into moveX[x]
where "x" is the name of the button, and you do this for each button
that needs to be moved.
Then, in the mouseMove message handler, you'd loop over each button
that needs to be moved, setting the loc of the button to its new x, y
coordinate. The new coordinate would be calculated using the x, y
coordinate parameter to the mouseMove message, and the values in the
moveX and moveY arrays.
As for keeping the list of the buttons, you've got a good start for
doing that in the script of the graphic object, but you'll need to
make the list of intersecting buttons available to the card script (as
a global variable, or better yet, as a custom property attached to the
graphic object). One suggestion, though. Currently you're
calculating the list of intersecting buttons using a "mouseWithin"
handler. I'm not a big fan of "mouseWithin" handlers, because like
idle handlers, they chew up a lot of CPU time for no good reason. You
really only need to recalculate the list on mouseDown and mouseUp, and
so I'd recommend doing it there instead.
Regards,
Scott
PS: I'm not sure what the policy is on this list about posting with
attachments (especially if you have to do it twice ;-) They frown on
this on most lists, but it can be very helpful to have the stack in
some cases (like this one), and as long as it's relatively small (less
than 10K or so) I don't see a problem with it. Anyone else?
> Thanks,
> Simon
>
> --
> [---------------------------------] Simon Lord
> [No matter how idiot proof you try] Database Engineer, CAE Electronics
> [to make any product, there will ] tel: (514) 341-2000 x3861
> [always be two people somewhere in] fax: (514) 340-5496
> [the world working hard at making ]
> [a bigger and better idiot. ]
> [---------------------------------] email: simonl@cae.ca
>
> ----------------------------------------------------------------------
> Arthur C. Clarke was quoted as saying he would prefer HAL, a super-
> computer named after the famous rogue intelligence in 2001 being
> constructed at the University of Illinois, to speak these as its first
> words:
>
> "Good morning doctors. I have taken the liberty of removing Windows 95
> from my hard drive".
> ----------------------------------------------------------------------
>
>
>
**********************************************************
Scott Raney raney@metacard.com http://www.metacard.com
Only 1% of computer users know a programming language...
MetaCard: We can change all that.