Drag & Drop from Windows Explorer

Try this site:

http://www.unitoops.com/uoole/examples/index.htm

Alex

Hi guys,

I saw this question not earlier because there's already an answer proposed. Please wait in future a while before answering, especially if you only have links for such a simple problem...

kerberus,

you don't need to setup all that OLE drag'n drop stuff only to accept files drop to your window. Use this stuff:

1) Call DragAcceptFiles(Handle, True); to indicate you're accepting files

2) handle WM_DROPFILES in the registered window:

type
  TMainForm = class(TForm)
  private
    procedure WMDropFiles(var Msg: TWMDropFiles); message WM_DROPFILES;
  end;

procedure TMainForm.WMDropFiles(var Msg: TWMDropFiles);

// the common game here if a file has been dropped on the application

var
  Buffer: array[0..MAX_PATH] of Char;
  Count,
  I: Integer;
  List: TStringList;

begin
  Count := DragQueryFile(Msg.Drop, DWORD(-1), nil, 0);
  List := TStringList.Create;
  for I := 0 to Count - 1 do
  begin
    DragQueryFile(Msg.Drop, I, Buffer, MAX_PATH);
    List.Add(Buffer);
  end;
  AddProjectFiles(List);
  List.Free;
  DragFinish(Msg.Drop);
  Msg.Result := 0;
end;


That's all. Only about 20 lines of code :->

Ciao, Mike

following...

As a comment to Liscke, WM_DROPFILES and related functions are provided for 16 bit backwards compatibility only. The recommended Win32 method of doing drag drop is to use the COM drag/drop interfaces. Don't criticize other peoples solutions unless you know your stuff.

Besides, with both mine (Drag and Drop Component Suite) and the UnitOOPS components you only have to drop a component on your form and write 1, maybe 2 lines of code and you're set to go.

i see mr Anders Melander has found e.e

welcome ;-)

does anyone know if  win2000 will still have the backward compatable api's?

So, this is Anders. You come in here talking big fam, not very nice. Btw. I know my stuff since I do it for a living, do you know yours?

Please direct me to a place where you have officially read that WM_DROPFILES is for backward compatibility only or even 16 bit stuff. My latest MSDN CDs (June 99) tell nothing about this. There are rather a couple of samples all using this message. There's even one of the most recent COM implementation (ITextHost, TOM if it has a meaning for you) which uses this message (as EN_DROPFILES in this case).

I found nothing mentioning that WM_DROPFILES should no longer be used or is old stuff. I'm also very sure it is still supported under Win2K. I like to use few code where few code is due and not large libraries just to do such a simple thing. I don't say anything against your libraries, Anders (I haven't even seen them) and assume they are good, so I will have a look very soon as I'm just working on a control which implements OLE drag'n drop (actually, the implementation is almost finished, but I need a way to combine VCL d&d and OLE d&d).

Ciao, Mike

Lischke,

I were out of line and I apologize for that. As should be evident, diplomacy isn't one of my best skills.

Anyhow, Yes, WM_DROPFILES is still supported (also for Win2K according to MSDN) and I'm sure it will continue to be supported for a very long time, but I still maintain that it is for backward compatibility. I wrote "16 bit backwards compatibility only", but what I really meant were "16 bit and backwards compatibility only".

I can not support my claim with hard proof, but AFAIR, I read it in a book or an article and took it for a fact. It also fits nicely with the fact that there is no (documented) drop source counterpart for DragAcceptFiles, that DragAcceptFiles is *emulated* internally in shell32 by an IDropTarget implementation and that WM_DROPFILES is generated only for the CF_HDROP format.

The fact that ITextHost mentions WM_DROPFILES doesn't, IMO, mean anything. AFAICT, in the case of ITextHost and ITextServices, EN_DROPFILES is generated only to support message based notification in addition to the IDropTarget interface implemented by the ITextHost object. It has nothing to do with DragAcceptFiles. In other words; A rich edit control doesn't receive a WM_DROPFILES because you have called DragAcceptFiles on it, but because it implements IDropTarget and has registered itself with RegisterDragDrop. The WM_DROPFILES is generated automatically for CF_HDROP drops.

I'll be happy to continue this discussion by email: anders@melander.dk

Hi Anders,

okay, apology accepted. Now that we have introduced ourselves to each other let's continue with the fun stuff :-)

Yes, I already assumed that WM_DROPFILES and related stuff is just a wrapper around a normal IDropTarget interface for any window to support at least dropping files from Explorer to an application which doesn't use OLE explicitly. Unfortunately, it is totally incompatible to Delphi's drag'n drop.

Anyway, I think we should wait for kerberus to answer and tell us if he needs more information.

Ciao, Mike

Thank you, experts!

I downloaded Melander's components and they are very good. I think he deserves points a few points for them, since he's not asking for money!

However, since inthe was the first one to suggest Melander's suite, I'll be awarding him the points.

Since I also used Lischke's code in a small application, he'll also be getting the points in a separate question.

I have another related question, in another thread, where I ask about how to change the cursor image (the mouse pointer) during drap'n'drop operations using DragAcceptFiles and COM. I already know how to do it from within my Delphi applications alone.

Again, thank you.
JK

Thanks.
I agree that inthe should get the points. Especially since I'm not really an active contributor to these fora.

For Lischke,

Regarding the status of WM_DROPFILES and related APIs, I just found the following in the October 1999 MSDN article titled "Handling Shell Data Transfer Scenarios":

General Guidelines
....
For data targets:
....
Implement and register an OLE drop target. Avoid using Microsoft® Windows® 3.1 targets or the WM_DROPFILES message, if possible.

Fine, thanks and a happy new year...

Ciao, Mike