Last edit: 05-03-17 Graham Wideman

Delphi

Introduction

This page describes the main features of the GWDropTarget unit, and the GWDropDemo application code.

GWDropDemo Application Architecture, How GWDropTarget Fits In

The diagram below shows the basic model.

The basic idea is that main apparatus that deals with COM is located in GWDropTarget.PAS, and can be used as-is in a variety of applications.  The piece that's specific to a particular app can inherit the basics and override selected functions for that app's needs.   This is demonstrated in the GWDropDemo application, which uses that GWDropTarget.PAS unit, and places all the app-specific drop functionality in DropDemoAppInterface.PAS.

The second piece to notice is that GWDropTarget.PAS contains two classes, not just the TGWDropTarget object that implements the IDropTarget interface. Why? Because extra functionality is needed to deal with the fact that once the IDropTarget object is handed over to the system, the system has some control over destroying it.  We therefore need someplace else to stick functionality that has a different lifetime.  This helper (TGWDropAppInterface) or its descendant turns out to be a convenient place to delegate the app-specific details of drag-time behavior, and dealing with the interface to the app's data, and the app's user-interface.

Finally, TGWDropTarget inherits from TGWMonInterfacedObject and consequently can cooperate with the monitoring apparatus in GWMonOLE.pas. This can be omitted if not needed.

Details

TGWDropAppInterface

constructor 
Create(AOwner: TForm;
UseMonitor: Boolean);
destructor Destroy;

function 
DropTarget_Create(
  AWinControl: TWinControl;
  Reg: Boolean
): HResult;

property 
DropTarget: TGWDropTarget;

function 
DropTarget_Exists: Boolean;

procedure DropTarget_Forget;

function 
DropTarget_LifeState: Tgwdt_ls;

function DragEnter(
  const dataObj: IDataObject; 
    grfKeyState: Longint;
             pt: TPoint; 
   var dwEffect: Longint
): HResult; virtual;

function DragOver(
    grfKeyState: Longint; 
             pt: TPoint;
   var dwEffect: Longint
): HResult; virtual;

function DragLeave: 
  HResult; virtual;

function Drop(
  const dataObj: IDataObject; 
    grfKeyState: Longint; 
             pt: TPoint;
   var dwEffect: Longint
): HResult; virtual

function Drop_StdEffect(
  grfKeyState: Longint
): Longint; virtual;

function Drop_Logic(
        phase: Tddp; 
      dataObj: IDataObject; 
  grfKeyState: Longint;
           pt: TPoint
): Longint; virtual;

procedure Drop_Feedback(
     phase: Tddp; 
        pt: TPoint; 
  dwEffect: longint
); virtual;

TGWDropTarget Notes

You should not have to modify TGWDropTarget or work with its functions and variables directly, though of course you may be interested in seeing how it works by looking at the source code.

One noteworthy feature is how TGWDropTarget resolves the potential Destroy-loop problem.  The nature of the problem is this:

• Our application must make sure that the DropTarget object is destroyed before the overall app exits.  The natural way to do this is to call Destroy.
• But you must not Destroy the DropTarget object until after you RevokeDragDrop and unlock the object by calling CoLockObjectExternal.  So Destroy should ensure that those functions are carried out...
• But if Destroy calls those functions, then they will decrement the object's COM RefCount to zero, causing the system to call Destroy.
• Calling Destroy from within Destroy will result in the outer Destroy attempting to destroy an object pointer that's already invalid because the inner Destroy already destroyed it (?!).  And it seems it's not good enough to set a "Destroying" flag, and have Destroy skip its body if it's already destroying... because immediately after Destroy the object's memory will be freed and the pointer will be invalidated anyway.

Possible Strategies:

• Never call Destroy from our code.  If we want the object to go away, then we should only call Revoke and unlock, which will then decrement the RefCount to zero and cause the system to call Destroy.
  • Problems:
  • If some other code has a reference to our object, then RefCount won't decrement to zero and the object won't get destroyed. But we need to destroy the object because it's useless without the accompanying window or our app, which we're presumably about to shut down. So we'd rather destroy the object definitively, and let the system deal with telling the other code that the object is gone.
  • Destroy is the standard way to get rid of a component so it's problematic to have to avoid calling Destroy in this special case.
• Better Strategy: We need a Destroy routine that:
  • Ensures that proper destruction occurs when either our app or the system calls it.
  • Ensures that Destroy doesn't call itself indirectly through RefCount going to zero.
  • Ensures that Revoke and unlock are both called just once.

This I have attempted to do in the TGWDropTarget code. 

Drop Effect (and Internet Explorer) Confusion

98-10-02: IE seems to create a lot of confusion for people wanting to write apps that accept URLs dragged from IE  (This discussion applies to IE 3.02, and presumably other versions too) .  The basic problem is this:  IE offers only a drop effect of DROPEFFECT_LINK, and wants the receiving app to respond with a request for the same. This means that apps that only look at the key-shift state to create their request will only be able to accept drops from IE when the user presses  <Ctrl-Shift> -- not entirely obvious to users.

Instead, drop-accepting apps apps should be careful to choose an effect from among those drop source offers, modified by what shift keys the user presses. This is incorporate in GWDropDemo in V1.12 and later.

Note that Netscape (at least as of V4.04) does not precipitate this confusion since it offers several drop effect options.

Go to:  Drop Demo Intro Page, or