This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: DragDrop Part 3 Feed Title: Pollock Feed URL: http://www.cincomsmalltalk.com/rssBlog/pollock-rss.xml Feed Description: Pollock - the next VW GUI Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Pollock

In our last installment, we left off with our hero, the user, after a thoughtful but pensive session moving the mouse, about to lift her right index finger

I just love cliffhangers

Now begins the fun. The user has released the mouse button over our target widget. Our DragDrop Session (the protagonist in our little story) sends a message to the target widget: "Bombs Away!" Here we stop short of actually going into detail as to what the target widget does, for the time being. Suffice it to say that our target widget will do the right thing, either adding the thing or things that have been dragged into itself, or telling one of it's contained items to somehow interact with the thing or things that have been dropped on it.

What happens next depends on if the DragDrop Session is a Move or Copy. If the DragDrop Session is a Copy, then our Session goes away, feeling happy that it completed it's life's goals. If however, the DragDrop Session is a Move, it has one last message to send before it fades into the great unknown. If the DragDrop Session is a Move, then the last thing it does is send the source widget the following message: "Mission Accomplished". (I think I have I somehow found myself too deep in a WWII metaphor)

For those with more literal minds, the above messages are more like "Drop" and then if it is a Move, "Drop Completed, Do Move Action". The point here is that if the goal is to move, we need to give the source widget the opportunity to probably remove the items being moved.

Now we need to start getting into the first level of details

All these messages, as you have seen, are sent to the widgets. We can easily imagine that the DragDrop Session, when it starts, collects up information about the thing or things that are being dragged, as well as information about the widget where the Drag started. We can also imagine that the widgets that are being dragged into, over and out of, are sent the various messages, with the DragDrop Session passed along as a parameter. That's the easy stuff.

What is harder to imagine is "How The Heck Can A Target Widget Know How To Deal With Whatever Is Being Dragged, Much Less Know It Is OK To Have Something Dropped On It?"

For instance, I saw a sort of interesting DragDrop ability in VSE (VisualSmalltalk Enterprise). If you started dragging a method name from a list of methods, and dropped it on a text pane, it would drop the text of that method where you dropped. Text widgets in and of themselves don't know how to take a "method object" and intrinsically know to find the source code in it and put that in itself.

In fact, an widget can't know how to do anything for ANY DragDrop Session. So, by default, when a DragDrop Session asks any widget "Can I Do A Drop On You?", it by default, has to answer "No!" In fact, by default, all widgets will answer ALL of the messages with an emphatic Sgt. Schultzian "I Know Nothing!" (There I go again, but at least I'm now in a Sitcom)

Time to take a quick trip into the deeper regions. When any of these messages are sent, we saw that the DragDrop Session is passed as a parameter. The DragDrop Session has a bunch of messages where it can accept information about how to react to various messages it is being passed. In the case of our first "Can I Do A Drop On You?" if the underlying widget does not send a "Ok To Drop On Me" message to the DragDrop Session, then nothing will happen. In other words, it takes a positive action, by the widget (or something else... hint, hint...) in order to change the default behavior. And, as noted above, the default behavior is always Do Nothing.

Here's where we are: No matter what, every widget in the world will not (and in reality, can not) talk back to the DragDrop Session. And because of this, it can not tell it that it is able to be participate of a DragDrop Session.

This leaves us with one question: "Why Are We Sending These Messages To The Widgets In The First Place? They Seem To Do Jack Squat!"

The answer is: Trigger Events

Next time, we'll finally start to get into the details, and describe how these messages are turned into Triggered Events, and thus can be captured by your application and, from there, be handled in an appropriate way.