You should file a bug/ecr so we can make it easier to get out of the chain of things considered as droptargets. And you're welcome to roll your own DragManager, but I was to avoid doing so, I think I would put a invisible droptarget on top of the whole car
________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Krotscheck Sent: Wednesday, October 03, 2007 1:45 PM To: [email protected] Subject: RE: [flexcoders] Bug in DragManager The way I'm rewriting it is that it skips over anything that's not an InteractiveObject. In my particular case, I'm selecting an item from a TileList (an Image) and letting the user drag/drop it onto a target that then displays said image. An example application (since I can't describe my own due to client non-disclosure agreements) would be placing decals onto a vehicle- there's a non-regular shaped area that a particular image can be placed into, and since the decal also needs to take on the shading of the car, it would have the following layers (top to bottom): DragObject (ignored by DragProxy) VehicleShading DecalMask DropTarget Now, I could adjust things so I can use setMask to lift the droptarget up one layer, but I still can't get through the shading overlay. Michael Krotscheck Senior Developer RESOURCE INTERACTIVE <http://www.resource.com/> www.resource.com <http://www.resource.com> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ________________________________________________________________________ ____ This email and any of its attachments may contain Resource Interactive proprietary information, which is privileged, confidential and may be subject to copyright or other intellectual property rights belonging to Resource Interactive. This email is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this email, you are hereby notified that any dissemination, distribution, copying or action taken in relation to the contents of and attachments to this email is strictly prohibited and may be unlawful. If you have received this email in error, please notify the sender immediately and permanently delete the original and any copy of this email and any printout. ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Harui Sent: Wednesday, October 03, 2007 4:17 PM To: [email protected] Subject: RE: [flexcoders] Bug in DragManager You're welcome to file a bug so we can think about it, but I think you're saying you want it so that non-mouseEnabled things like Shapes and Bitmaps can't be drop targets or block something else from being the droptarget, which seems kind of restrictive. Are you using the canvas as a "shield" or are things just overlaid in your app? ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Krotscheck Sent: Wednesday, October 03, 2007 12:12 PM To: [email protected] Subject: [flexcoders] Bug in DragManager So, I've been working with the DragManager for a bit now, and I'm wondering whether or not what I've found was a design decision or simply an omission. Cosnider the case of having a mouseEnabled="false" component (in my case a Canvas) lying on top of a drag target. The following few lines of code (DragProxy.as 357-366): // targetList is in depth order, and we want the top of the list. However, we // do not want the target to be a decendent of us. var targetIndex:int = targetList.length - 1; while (targetIndex >= 0) { newTarget = targetList[targetIndex]; if (newTarget != this && !contains(newTarget)) break; targetIndex--; } ignores the mouseEnabled state, and the subsequent code fires the DRAG_OVER event on the topmost non-selfcontained child in spite of whether it should be receiving events. Now this could be easily solved (the way I'm doing it) by overriding the appropriate function to check for mouseEnabled, or to add a new property to InteractiveComponent like isDragEnabled (since dragEnabled is used elsewhere for a different scope), but I'm curious as to whether I'm missing an underlying architectural decision. Michael Krotscheck Senior Developer RESOURCE INTERACTIVE <http://www.resource.com/> www.resource.com <http://www.resource.com> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ________________________________________________________________________ ____ This email and any of its attachments may contain Resource Interactive proprietary information, which is privileged, confidential and may be subject to copyright or other intellectual property rights belonging to Resource Interactive. This email is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this email, you are hereby notified that any dissemination, distribution, copying or action taken in relation to the contents of and attachments to this email is strictly prohibited and may be unlawful. If you have received this email in error, please notify the sender immediately and permanently delete the original and any copy of this email and any printout.
