Matt, when you say "shallow copies" below do you really mean references? I jsut ran across behavior where the dragSource items changed between the beginning of the drag and the dragDrop event. This happened because in the dragOver event handler I was changing the selectedIndex on the drag initiator. When this happens, the dragSource items became the new selectedIndex, not the item that was actually being dragged. Is this a bug or an undocumented feature?
-- Howard Fore, howard.f...@hofo.com "The universe tends toward maximum irony. Don't push it." - Jeff Atwood --- In flexcoders@yahoogroups.com, Matt Chotin <mcho...@...> wrote: > > So a DragSource is a little more than that. Check out the addHandler method > for example. What happens is your source (e.g., the List) will create a > DragSource, and then give the DS a function to say "hey, if someone asks for > data of this format, call this function to get the data." This can be > really useful if it would be computationally expensive to give the data in a > certain format. The List is a perfect example of this (and it leads to an > answer for Dave). The List (and subclasses) DataSource has two formats > stored, "source" and "items." The "source" is the List where the dragging > was initiated. Easy enough. The "items" are in fact shallow copies of the > items that were in the dataProvider that are being dragged across. So if > you are dragging 3 items from a List the "items" data is going to be an > array of those 3 items. This is where the handler function comes in. How > many times have you started to drag something and then never ended up > dropping it somewhere? I do it a lot. Now what if creating that new array > of items from the List is computationally expensive (it is because there's a > copy being made), you wouldn't want that to happen the minute the user > starts dragging, right? You really only want it to happen the first time > someone asks for the items. So the handler function allows us to delay the > work that goes into returning that array of items, only calling the > expensive operation when it's actually needed. > > > > Thus the need for a real class to do some of this dirty work. Make sense? > > > > Matt > > > > _____ > > From: JesterXL [mailto:jeste...@...] > Sent: Friday, January 21, 2005 2:22 PM > To: Flexcoders > Subject: [flexcoders] wtf is a DragSource > > > > Ok, this is the weirdest class I've ever used in my life. Correct me where > I'm wrong; if your bored, feel free to fill in the blanks. > > A dragSource is a class used to hold data. This data, in effect, helps give > > those handlers who respond to drag events context about what's going on, and > > who's currently being dragged. At a low level, one can use the dragSource > to stuff in referneces to those who were dragged, say a List, and then later > > in the drop function, grab items from that list indirectly; since your using > > a refernce, no need to hardcode references to objects since the dragSource > has it, allowing your dropfunctions to remain dumb. > > ....am I even close? Why not just use a vanilla object like > EventDispatcher?
