I can't speak to Adobe's intent, but I regularly avoid startDrag because I need more fine control over the drag. For example if you want to program a drag that implements "snap to" functionality, you're going to want to have direct control over the placement of the object, instead of letting the player handle it. As I said, I don't know why Adobe did it in this case, but here's an example of why someone might want to do it somewhere.
- Dan On 2/9/07, Derrick Grigg <[EMAIL PROTECTED]> wrote:
> I can't find anywhere that we use startDrag()in the framework, > including in the DragManager. My bad, you know what they say about 'assuming'. Just did some more digging, in the DragProxy class and was very surprised to see that it actually uses a mouse move event listener and then repositions the drag proxy based on the the x/y of the mouse. var pt:Point = new Point(); var point:Point = new Point(event.localX, event.localY); point = DisplayObject(event.target).localToGlobal(point); point = DisplayObject(dragInitiator.systemManager.topLevelSystemManager ).globalToLocal(point); var mouseX:Number = point.x; var mouseY:Number = point.y; x = mouseX - xOffset; y = mouseY - yOffset; This just begs the question, why??? Why go through all that instead of just using the startDrag that is a core method of the Sprite class? Just to offset the DragProxy slightly from the mouse pointer? I don't get it, why bloat (in my opinion) the code. From my understanding classes and methods that are actually compiled into the flash plugin (ie the flash.* package) run faster than those that are not (ie. the mx.* package). I don't understand why all the extra code is required to accomplish something the plugin already has the ability to do.
