There is nothing wrong with your television set. Do not attempt to adjust the picture.
Latest version: 5.2
Released: 17 aug 2010
The Drag and Drop Component Suite is a freeware VCL component library that enables your Delphi and C++Builder applications to support COM based drag and drop and integrate with the Windows clipboard.
The drag and drop system that is built into the VCL, is limited in that it only supports drag and drop within the same application. If you need to drag data from your application to other applications (e.g. Word, Explorer or Outlook), or if you need to be able to accept data dropped from other application (e.g. the Explorer), you have to use COM based drag and drop. COM based drag and drop is an integral and very important part of the Windows user interface and the Drag and Drop Component Suite makes it very easy to leverage all the features of COM based drag and drop in your own Delphi and C++Builder applications.
Every drag and drop operation involves two objects: A drop source and a drop target. The drop source provides the data to be dragged, and the drop target accepts the dragged data.
Likewise there are basically two sets of components in the Drag and Drop Component Suite; Drop source components and drop target components. Most of the source and target components are specialized to handle just one type of data, but a few of the components supports a wider range of data types or are completely generic.
In addition to the drag and drop components, the Drag and Drop Component Suite also includes components that can be used to build Windows Shell Extensions. While these components aren’t all related to Drag and Drop, they benefit from the Drag and Drop Component Suite framework and allow you to write Windows Shell Extensions with very little code. But most important; I had a lot of fun writing them :-).
The Drag and Drop Component Suite contains the following components:
|Drop Sources||Drop Targets|
This work is licensed under a
Creative Commons Attribution-Share Alike 3.0 Unported License.
The library has been tested with the following versions of Delphi:
If you can confirm compatibility with any of the untested versions of Delphi (or C++ Builder for that matter), please let me know and I will update the table.
I have done absolutely no testing with C++ Builder so I don’t know if the code works with it or not. That said, according to feedback I have received, the current release should work with C++ Builder.
|Download:||The Drag and Drop Component Suite v5.2|
|Updated:||17 August, 2010|
|Notes:||Includes component source and demo applications.|
Old versions can be found on the downloads page.
Packagesfolder, find the design time package that matches your version of Delphi. Open it in Delphi, Compile and Install.
Librarysub-folder that matches your version of Delphi. Add it to the Delphi library search path.
Sourcefolder to the Delphi browsing path.
Drag and Drop Component Suitedesign time package.
Libraryfolder from the Delphi library search path.
Sourcefolder from the Delphi browsing path.
Changes since version 4.2:
TRawClipboardFormatthat caused it to stop functioning after first use.
TDropContextMenunow properly supports nested context menus.
DragDetectPlushas been improved to make it possible to use it with popup menus and
TCustomDropTarget.Enabledhas been improved.
DragOverwill not call
ResetScrollZoneif a custom scroll zone has been specified through the
NoScrollZoneproperty thus if the user specifies a custom scroll zone in
OnDragEnterthen the scroll zone will not be automatically reset in
TStorageDataFormathas been improved based on user feedback.
TFileContentsStorageClipboardFormatnow handles both Ansi and Unicode data. Among other things this fixes problems with Outlook drop targets.
CopyToStgMediummethods are now functions that return a boolean. The return values indicates if the method was able to perform the requested operation.
MappedNamesproperties are no longer published. They are now public properties.
MakeRTFfunction in the
DragDropTextunit failed to compile with some versions of Delphi.
DragDetectPlusno longer eats right-click mouse messages.
OnGetDataevent) instead of when the data is dropped (
OnDropevent). This change was made to handle application that require the files to be physically present when ever they query the drop source for the file names.
TListView’s internal mouse message handling makes it impossible to handle right-click correctly.
TMessagesclass (used for Outlook drag/drop) now support sessions. This can be (and is) used to work around the various quirks in Outlook’s interface reference counting mechanism.
TAnsiStringClipboardFormat.GetClipboardFormathas been implemented.
TCustomDropTarget.PasteFromClipboardno longer clears the data after the OnDrop event has fired.
TClipboardFormat.GetDatathat caused drop targets to reject data after first drop.
TTextDataFormatthat mainly affected
TDropFileTarget.OptimizedMoveis now declared correctly.
AssignTocompatible with it.
TWideStringListfor Unicode support, now use the new
DragDetectPlusfunction now leave mouse click messages (
WM_xBUTTONUP, etc) in the message queue.
MakeRTFutility function now support Unicode strings and generate proper RTF formatted text.
TVirtualFileStreamDataFormatclasses has been moved to the DragDropFile unit.
T*TextClipboardFormatclasses has been moved to the DragDropText unit.
CreateIStorageOnHGlobalwhich primarily affected drag/drop from Outlook.
TFilenameClipboardFormathas been renamed
TFilenameWClipboardFormathas been renamed
TFilenameClipboardFormatis now an alias for the native (ansi or unicode) format.
TFilenameMapClipboardFormathas been renamed
TFilenameMapWClipboardFormathas been renamed
TFilenameMapClipboardFormatis now an alias for the native (ansi or unicode) format.
TFileGroupDescriptorClipboardFormathas been renamed
TFileGroupDescriptorWClipboardFormathas been renamed
TFileGroupDescriptorClipboardFormatis now an alias for the native (ansi or unicode) format.
TTextClipboardFormathas been renamed
TCustomTextClipboardFormathas been renamed
TCustomWideTextClipboardFormathas been renamed
TTextClipboardFormatis now an alias for the native (ansi or unicode) format.
TTextDataFormatnow keeps string data data in the source format and only converts between unicode and ansi on demand.
TTextDataFormatis now named
TTextDataFormatnow returns the native string format.
HTMLproperties of the
TTextDataFormatclasses are no longer supported and have been removed.
TDragDropHandler.GetFolderPIDLfunction has been replaced with the
TURLClipboardFormathas been renamed
TURLWClipboardFormathas been renamed
TURLClipboardFormatis now an alias for the native (ansi or unicode) format.
TURLDataFormatis now a Unicode string.
constdirective to interface parameters.
TFileGroupDescriptorCustomClipboardFormatas common ancestor for
In short, you can’t.
You must understand that the drag/drop API works the same for all applications that uses it, and the Explorer is just like any other application. The drag/drop API provides a framework that facilitates the interaction between a drop source and the target, but since the drop target can do anything it wants with the data it receives, there is no way to communicate the destiny of the data back to the drop source in a uniform way.
One target may chose to display the dropped data (e.g. notepad), another one to upload it to a web server (e.g. a FTP client), a third to move and rename the file (e.g. the Recycle Bin) and a fourth may chose to copy or move the file (e.g. Explorer).
In my experience there is never any real need to know the destination of a drop to the Explorer. If you find that you do need this, you should rethink your solution. - and feel free to ask for help.
AllowAsyncTransferproperty and the
Asynchronous parameter specifies if the source should perform the transfer in a thread.
AllowAsyncTransfer property specifies if the drop target is allowed to perform an asynchronous transfer.
The two are completely independent. One does not have priority over the other.
Asynchronous transfer on the source side is an “invention” of mine. It can be done even if the drop target doesn’t support, and thus doesn’t take an active part in, asynchronous transfer.
Asynchronous transfer on the target side is a COM drag/drop feature (see
IAsyncOperation in MSDN). It requires that both the source and the target support asynchronous transfer. All the Drag and Drop Component Suite components support asynchronous transfer, but apart from Windows Explorer few applications has implemented the feature.
An optimized move is simply a move operation where the drop target moves the data from the source to the destination location.
In a conventional move operation, the source and the target must cooperate in order to complete the operation. First the target makes a copy of the data at the desired location. Then, when the target has completed copying the data, it hands control back to the source who then deletes the original data. This procedure can be very inefficient because it requires two simultaneous copies of the data.
With an optimized move, the target handles the entire move operation and signals the source that an optimized move took place upon completion.
The Drag and Drop Component Suite supports Optimized Move on both the source and target side.