This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: DragDrop Part 2
Feed Title: Pollock
Feed URL: http://www.cincomsmalltalk.com/rssBlog/pollock-rss.xml
Feed Description: Pollock - the next VW GUI
I wish I had good analogies for GUI Framework work. Last night I was watching the third episode of The Elegant Universe on PBS. It's all about The Theory of Everything and String Theory and Physics. Anyway, they had this one really cool analogy describing how M/String Theory probably describes Gravity, using a Pool Table. I can't explain it myself, but I must say, when I saw that (and several others they had on the show), I was amazed at how much closer I was to understanding what it is all about.
Back to my obtuse and labored explanations <sigh>
I left off with my saying I'd be talking about DragDrop and Pollock. Of course, I won't start there... I promise, I'll get there soon.
We need a bit more detail on our overall view of DragDrop. So, we're going to move from orbit and skim closer to the surface.
We need a picture in our mind (as close as I get to an analogy) to play with. Let's say a DragDrop drag has already started. The user has clicked on something somewhere, not released the mouse button, and has started to move the mouse around. Details of how the DragDrop started isn't important for this picture right now.
The mouse is now entering a widget that may or may not accept the dropping of whatever is being dragged. Again, for this picture, it doesn't matter if the drag started in the same widget that we are now entering, or if it started from another widget. So, the first thing that has to happen is that the DragDrop in progress, we'll call it a DragDrop Session, is it has to ask the widget that it is just entered if it can even accept the drop of whatever is being dragged.
Taking the easy course first, we'll say that the widget being entered, when asked this question just says "No"! (at this time, in our picture, it doesn't matter why). The DragDrop Session in response will tell the system that the cursor should change to the universal "No"! cursor (the circle with the slash through it. As the user drags over that widget, and until it exits the bounds of that widget, the No cursor will be shown. As the drag moves out of our target widget, it is up to the window or another widget to answer the can I drop here question, and is no longer an issue for our target widget, nor the picture we're building
Now, let's take the harder to describe case. We'll now say that the widget being entered, when asked by the DragDrop Session if that widget will accept a drop in itself, it says "Yes" (again, we aren't as yet looking into how the question is asked, or the reason our target widget answered "Yes"). First thing, the DragSession does, is to tell the target widget to "Display Drop Emphasis". This means, it tells the widget "If you want to somehow show that you are OK to have this drop be done in you, now is the time to display some kind of hint that this is so, if you want." Examples of this come in many forms. I have seen some widgets simply draw a dashed line around the inner bounds of the widget. One nice example I found when using XMLSpy is when you are dragging an item in a list, it draws a heavy dark line between items in the list, showing where the item you dragging will be put if you drop. Another example, when you are dragging to drop ONTO the Recycle Bin in Explorer is that the target item is itself highlighted, as if selected.
As we continue to drag over the widget that has said "Yes", the DragSession sends a pair of messages to the target widget. The first, is "Hide Drop Emphasis" followed immediately by a "Display Drop Emphasis". A further bit of detail is needed here. Whenever a DragDrop Session is sending a message to a widget, it passes itself as a parameter to the message. It updates itself with mouse position information, as it does so. In this way, the "Hide Drop Emphasis" message is sent with the DragDrop Session having the same mouse position information as the previous "Display Drop Emphasis". Then, the "Display Drop Emphasis" messages sent to our target widget is sent with the DragDrop Session having the new mouse position information in it. This way, our target widget will have enough information, by querying the DragDrop Session, to figure out how to display or hide emphasis, if it wants to.
Finally, as the we drag the mouse OUT of the bounds of the widget, one last "Hide Drop Emphasis" is sent to our target widget
You probably notice that the exact nature of how these messages are sent and so on, is not detailed yet. We'll get there.. but not just yet. First we'll have to talk about what happens when you actually drop an object.
Previous Topic
