okay I have altered DragDrop to work with three different drop algorithms - mouse, overlap, enclosed. To set the drop algorithm you wish to use I have created a new property for DragEvent. DragEvent.setDropType(lyr, "overlap") //where overlap could me mouse or enclosed. The side effect of this is that it doesn't try to do a detection for a child unless this is defined - which gives a small speed increase.
Please take a look at this code and send me the criticism so I can get it right, as I would love to be able to add to the project. some of my own thoughts: currently the "drop" event must be defined for every object you might drop the source onto. This means that you don't have a drop event that tells you the targeting layer, if one hasn't been setup. So I think an event needs to be in place for the source that can tell you what the target is whether the target has a onDrop listener on not - anyone have any ideas for a good way of doing this? I think grouping would be nice too. While I might setup my ondrop event I may only want it to fire for certain layers - or have different onDrop events for different targets. So I think it would be nice to an array that holds other layers that would fire the event. you can either hold layers, or hold groups which contain layers Does this make sense? Anyone got any good ideas on how to implement this? Another great project would be pixel level detection - although I won't be working on this. I think if a bitmap mask (an array of 1,0 for each pixel in the layer) is specified for the source and target it should try to pixel level collision detection - this would be great for games - any takers? What are your thoughts? Mark At 13:18 23/03/2002 +1100, Michael Pemberton wrote: >Mark Proctor wrote: > >>described below - how would I implement this, different include files?: >>DrapDrop >>DragOverLap >>DragEnclose >>What about optimisation? Is there or can we build global arrays for each >>listener type, holding all the objects registered for that listener? > >I will start with a side comment, if you know that someone is a member of >this group, it helps to not post it to them twice. This is especially >noticable when signed to both lists that a message is cross posted to : ) > >That said, your code should always be written as an extension of the >API. Expecially code that alters the internal functionallity. Also, with >regards to optimisation, you have just remove the one line of >optimisation code that existed. ; ) > >The line that reads: > if (ch.DragDrop(s,e)) return true; >is designed to work in such as fashion that once an object has been >dropped, there is no more need to check for possible drop zones. > >-- >Michael Pemberton >[EMAIL PROTECTED] >ICQ: 12107010 > > > > > > >_______________________________________________ >Dynapi-Dev mailing list >[EMAIL PROTECTED] >http://www.mail-archive.com/[email protected]/Title: DynAPI2 Tutorial - dragging within our boundaries
dragdrop.js
Description: JavaScript source
dragevent.js
Description: JavaScript source
