Added July 2021

xcall MIAMEX, MX_DRAGDROP, opcode, status, ctlid {,fidx ,fspec}

MIAMEX function MX_DRAGDROP (199) provides support for accepting files dragged and dropped from Windows File Explorer—or another Windows Shell object—onto a control created with AUI_CONTROL.

To enable the feature, specify the WS_EX_ACCEPTFILES (&h0010) flag in the winstylex parameter of the AUI_CONTROL call when creating the target control. Typically this would be a static control, perhaps with a colored background and some explanatory text (e.g. “"Drop files here"), but in theory it could be nearly any control type—including dialogs—that are created with AUI_CONTROL.

Two modes are supported: destructive and non-destructive. In the destructive mode, each drop event replaces the existing contents of the drop buffer with the newly dragged file specs, as with a clipboard Copy. In the non-destructive mode, each drop event adds to the existing contents of the drop buffer. Destructive mode is the default. Non-destructive mode is established via MX_DRAGDROP opcode 3 after creating the drop target control.

In both modes, the drop event triggers exitcode -75,notifying the application so that it can respond by querying and/or retrieving the filespecs using the MX_DRAGDROP function.

Parameters

opcode  (Num)  [in]

status  (Signed Num)  [out]

<=0: failure, or no files available in opcode 0; >0: success, which is the number of files for opcode 0, or the number of bytes in fspec for opcode 1

ctlid  (String )  [in]

control id of the target control

fidx  (Num)  [in]

for opcode  1, must be set to the number of the fspec to retrieve (starting with 1)

fspec  (String ) [out]

file specification returned for opcode 1

Comments

Note that it isn’t actually the files themselves that are being dragged and dropped; it is just their file specifications.

Although the implementation is primarily on the Windows side, accessing the new MX_DRAGDROP feature from an ATE session will require that the server instance of A-Shell also be at least at version 6.5.1705.

There is nothing stopping you from defining more than one drop target control within a given UI context. But since all drop events trigger the same exitcode -75, you would need to query each of the possible drop target controls in order to identify which control received the drop event.

Examples

Create a drop target control—in this case, a static text control. The critical element here is the WS_EX_ACCEPTFILES value for the winstylex parameter.…

! create the drop target (must be MBF_STATIC with WS_EX_ACCEPTFILES)

DROPCTLID$ = “txtDropTarget”

xcall AUI, AUI_CONTROL, CTLOP_ADD, DROPCTLID$, &

    "Drop File(s) Here" + chr(13) + "Click to query", MBST_ENABLE, &

    MBF_STATIC+MBF_CENTER+MBF_KBD, "VK_xF100", NUL_FUNC$, NUL_CSTATUS, &

    srow,scol,erow,ecol, NUL_FGC, &hddccbb, &

    NUL_FONTATTR, NUL_FONTSCALE, NUL_FONTFACE$, NUL_TOOLTIP$, &

    DLGID$, NUL_WINCLASS$, NUL_WINSTYLE, WS_EX_ACCEPTFILES, &

    NUL_CTYPE2

Set asynchronous mode:

opcode  = 3

ctlid = DROPCTLID$

xcall MIAMEX, MX_DRAGDROP, opcode , status, ctlid

Query drop target to see how many files are available:

opcode  = 0

ctlid = DROPCTLID$

xcall MIAMEX, MX_DRAGDROP, opcode , status, ctlid

count = status   ! # of files in target

Retrieve file specifications from the drop target:

opcode  = 1

ctlid = DROPCTLID$

for fidx = 1 to count   ! count retrieved from opcode 0

    xcall MIAMEX, MX_DRAGDROP, opcode, status, ctlid, fidx, fspec$

    ? “File #”;fidx;” : “;fspec$

next fidx

Also See

•   The sample program FILEDROP1.BP in EXLIB:[908,90] illustrating a simple drag-drop user interface.

History

2021 July, A-Shell 6.5.1705:  Function added to A-Shell.