OLEDropHasData, OLEDropEffects

Hacker’s Guide to Visual FoxPro
An irreverent look at how Visual FoxPro really works. Tells you the inside scoop on every command, function, property, event and method of Visual FoxPro.

OLEDropHasData, OLEDropEffects

These properties give the drop target a chance to decide how to handle dropped data. OLEDropHasData indicates whether the drop target is compatible with the data being dragged. OLEDropEffects determines the actions the drop target supports.

Usage

oObject.OLEDropHasData = nIsItAcceptable
nIsItAcceptable = oObject.OLEDropHasData
oObject.OLEDropEffects = nActionsAccepted
nActionsAccepted = oObject.OLEDropEffects

Parameter	Value	Meaning
nIsItAcceptable	-1	Let VFP figure out whether this drop target can accept any of the data that's being dragged. This is the default.
	0	The drop target can't accept any of the data that's being dragged.
	1	The drop target can accept some form of the data being dragged.
nActionsAccepted (add all desired values together)	0	The drop target doesn't accept any drops.
	1	Data can be copied to this target.
	2	Data can be moved to this target.
	4	A link can be created between this object and source data. This option isn't relevant for native VFP objects because they don't have the capability of handling linked data.

These properties are both involved in deciding what a drop target does with a particular drop. OLEDropEffects indicates what kinds of drops are accepted. Like many of the OLE Drag and Drop properties, you add together all the values that apply. (Since 0 is always part of the result, doesn’t that mean that no drops are ever accepted?)

OLEDropHasData goes farther. It says whether the particular data being dragged at this moment can be dropped on this target. As George Carlin (and we, elsewhere in this book) said, “Why are there three?” But this one makes sense (except for the actual values used). You can say “No, there’s no relevant data,” “Yes, there is useful data here” or “I dunno. Why don’t you figure it out for yourself?”

OLEDropHasData is an unusual property—it can be changed only at runtime, not at design-time. That’s because you set it for a particular drag operation.

At first glance, it might be hard to see why you’d ever want to set OLEDropHasData to anything but -1. In fact, it might be hard even at second glance. After all, can’t VFP just figure out whether there’s relevant data and behave accordingly? But, in fact, OLEDropHasData is one of a set of properties and methods that make OLE Drag and Drop very cool. First, it lets you drop data onto things that wouldn’t normally accept the drop. For example, you might allow a text string to be dropped on a form and set the form’s caption to that string. (No, we don’t know why you’d ever do this, but we did it, as we were working our way through understanding the subject.) To do that, you have to tell the form that, despite its feelings to the contrary, it can accept drops of textual data. (Then, in the form’s OLEDragDrop method, you write some code that sets the Caption to the dropped string.)

Like most of the OLE Drag and Drop properties, these two have their constants included in FoxPro.H. Use the constants for much more readable code.

In addition, you can create your own data formats. In that case, there’s no way that VFP can figure out whether a particular object can accept that data. You set OLEDropHasData to 1 if this target accepts your custom format. There’s an example of this in the OLEDrag section.

Example

* Say, text dragged onto a form should be used
* to change the form's Caption. In the form's OLEDragOver
* method, put this code:
#INCLUDE FOXPRO.H
IF oDataObject.GetFormat(1)
   This.OLEDropHasData = 1
   * allow either move or copy
   This.OLEDropEffects = DROPEFFECT_COPY + DROPEFFECT_MOVE
ENDIF