OLEDragDrop in VFP8

[KeithTrangmar]

I've successfully implemented OLEDragDrop in a VFP6 project so that my users can drag-and-drop a file anywhere on the application and a method fires to determine what to do with it. I cribbed the code from

http://fox.wikis.com/wc.dll?Wiki~ScreenMethods~VFP

Having now upgraded the project to VFP8, I've had to rework it slightly to use BindEvents(), which is also demonstrated in the same article. But now it's not working - it seems that the OLEDragOver event code isn't being called, as the "wait window" commands that I've added for debugging don't appear. My code looks like this:

public oSH
oSH = NEWOBJECT("ScreenHook")
BINDEVENT(_SCREEN,"OLEDragOver",oApp.oSH,"myOLEDragOver")
BINDEVENT(_SCREEN,"OLEDragDrop",oApp.oSH,"myOLEDragDrop")

DEFINE CLASS ScreenHook AS CUSTOM

oScr = _SCREEN
oScr.OLEDropMode=1
oScr.OLEDropEffects=3 && Move and Copy

FUNCTION myOLEDragOver
LPARAMETERS oDataObject, nEffect, nButton, nShift, nXCoord, nYCoord, nState
do case
case oDataObject.GetFormat(15)
	this.OLEDropHasData=1
	nEffect=1
case oDataObject.GetFormat(1)
	wait "OLE data is text" wind nowait
case oDataObject.GetFormat(7)
	wait "OLE data is OEM text" wind nowait
case oDataObject.GetFormat(13)
	wait "OLE data is Unicode text" wind nowait
otherwise
	wait "OLE data is unknown format" wind nowait
endcase
ENDFUNC

FUNCTION myOLEDragDrop
LPARAMETERS oDataObject, nEffect, nButton, nShift, nXCoord, nYCoord
local aFiles(1)
if oDataObject.GetData(15,@aFiles) and alen(aFiles,1)>0
	&& Do something with the array of filenames that has been passed as a parameter...
endif
ENDFUNC

ENDDEFINE

Am I doing something obvious?



Keith Trangmar
Harlend Computer Services
Maidstone, Kent. UK.

 

[Mike Lewis]

Keith,

Sorry I can't answer your question. However, I'm not clear why you had to rewrite the code. I'm not aware of anything in VFP 8.0 that would break your 6.0 drag-and-drop code. Is there a good reason for not leaving the 6.0 code as it was?

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-consult.com)

 

[KeithTrangmar]

Hi Mike

In the VFP6 code, the functions within the class were declared as oScr.OLEDragOver(), and VFP8 didn't like this. Sure enough, when I referred back to the original article, someone else had documented this & provided the alternative declaration (above). I should clarify that I've oversimplified this for succinctness - I also have a Resize() function defined, hooked into the screen so that the "master" form recentres itself each time, and this is working fine under VFP8, so it appears that the use of BindEvent() isn't necessarily the root of the problem.

Thanks,



Keith Trangmar
Harlend Computer Services
Maidstone, Kent. UK.

 

[ChrisRChamberlain]

Keith

How can I add .Resize() and .Moved() methods to _SCREEN? faq184-4374

may provide alternative code to that which you are currently using. You'll see it uses BINDEVENT() in VFP8.

Although it requires more coding, you may find it easier to implement OLE drag 'n drop on specific controls as opposed to the blanket approach currently deployed as you have more control over events, and by dispensing with the 'drop anywhere' approach you are also dispensing with your problem.

FAQ184-2483 - answering getting answered.​

Chris
PDFcommander[sup]tm[/sup].com
PDFcommander[sup]tm[/sup].co.uk

 

[KeithTrangmar]

Thanks Chris

Unfortunately it doesn't demonstrate anything I don't already know, as my _screen.Resize() event code is working just fine. I'm loath to have to remove the existing functionality which my client enjoys in VFP6, but must concede that I haven't actually tried it on a form-only basis yet so there may be issues with that too, and maybe the answer will be more obvious if I do. If need be, I suppose I can add the oledragdrop functionality to the app's form baseclass and maybe put in a big invisible always-on-bottom background form....



Keith Trangmar
Harlend Computer Services
Maidstone, Kent. UK.

 

[ChrisRChamberlain]

Keith

Th reason for suggesting implementing OLE drag 'n drop on specific controls is that at any one time there may be only one or two controls in a single form or MDI interface that would be regarded as legitimate targets.

FI, if you want to drag ' n drop text as well as files, you need to differentiate between the data types in the 'global' OLEDragOver() event.

So for files, the drop zone might be a grid - for text, the drop zone might be a editbox.

The OLEDragOver() event for each control would be specific to the data type to be dropped.

Dropping a bunch of files onto an editbox could not happen and vice versa with text onto a grid.

With the method you've adopted, if I understand it correctly, any part of the form(s) or any control, even a label or a line, is shown to be a drop zone?

FAQ184-2483 - answering getting answered.​

Chris
PDFcommander[sup]tm[/sup].net
PDFcommander[sup]tm[/sup].co.uk

 

[KeithTrangmar]

Chris

In the context of this particular application, dropping text isn't an issue as it's never needed, but dropping files is. It's not used that much, perhaps a couple of times a day by four or five of the (20-odd) users, but when it is, it's always to import files. There could be any one of a 6 forms open at the time, depending on the user's rights & the context in which they're using it (call centre, admin, warehouse or despatch) and these various forms only take up limited screen space. These files being imported are usually spreadsheets or CSVs from third parties, and their contents get dumped into the relevant tables then the files themselves are discarded, and optionally erased.

It's a very specific niche context in which I'm using drag-and-drop here, and frankly I don't care if it's the "done" thing or not, it works that way now under VFP6 and nobody wants to lose the functionality they're now familiar with when I upgrade them to VFP8. I appreciate it could be done with GetFile() dialogues and the like instead but I've done it this way for the convenience of the (relatively high number of) older users that we have who are not so computer-literate and were hired for their other talents. For those of them who are only just coping with email, it's a LOT easier for them to drag an attachment out of a message and simply drop it somewhere in my application, than having to decide where to save it then open up another form (perhaps cancelling what they already had open) in order to import it...

I'll concentrate on trying to get it to work on a stand-alone form for now, and see where I go from there.



Keith Trangmar
Harlend Computer Services
Maidstone, Kent. UK.

 

[ChrisRChamberlain]

Keith

Thanks for the explanation and good luck.

FAQ184-2483 - answering getting answered.​

Chris
PDFcommander[sup]tm[/sup].net
PDFcommander[sup]tm[/sup].co.uk