When the user drops a dragitem over a Presentation Manager window, the target receives a DM_DROP message. The window procedure for the target may process that message in order to handle the drop operation, and may either complete the operation or initiate a conversation with the source window or object in order to do so, typically by sending it a DM_RENDER message, which ultimately will result in the data being transferred.
When the user drops a dragitem over a Workplace Shell object, the Workplace Shell invokes that object's _wpDrop method. The processing of this method is very similar to that discussed below for the DM_DROP message. However, object classes that do not implement private rendering mechanisms need not override the _wpDrop method; the default processing provided by the parent class may be allowed to occur.
In the customer/phone dialler example, the only type of dragitem that the order program will accept is a customer object, which uses the application-defined DRM_SHAREMEM rendering mechanism. The correct data type and rendering mechanism is verified by the target window procedure during processing of the DM_DRAGOVER message, so there is no need for further checking when the DM_DROP is processed. Note however, that in a more sophisticated application, which supports multiple data types and rendering mechanisms, it may be necessary to perform more detailed checking.
In Figure "Handling the DM_DROP Message", access must first be gained to the DRAGINFO and DRAGITEM structures. This is achieved in a similar manner to that already described for the DM_DRAGOVER message. Having gained access to these structures, a named shared memory object is then allocated, into which the source window will be asked to place the customer details.
A DRAGTRANSFER structure is then allocated, in which information about the target's requirements can be passed to the source window. This structure is similar to the DRAGINFO structure, in that it must be accessible from multiple processes. It is therefore allocated using the DrgAllocDragtransfer() function, ensuring that the structure will be accessible to the source window, which may be in another process and therefore not have direct access to the target's private data areas.
There are several important fields in this structure. The target window procedure places a pointer to the DRAGITEM structure into the pditem field, thereby enabling the source to identify which item has been dropped. The hstrSelectedRMF field is used to identify which rendering mechanism and data format is to be used for this target, from the selection offered by the source in the DRAGITEM structure. The hstrRenderToName field is used in the DRM_SHAREMEM rendering mechanism to pass the name of the shared memory object to the source window.
Once this structure has been completed with the necessary information, it is sent to the source window as part of a DM_RENDER message. This message is passed to the source window using the DrgSendTransferMsg() function. This function should be used for drag/drop operations in preference to the WinSendMsg() function since, for a DM_RENDER message, it also grants access to the DRAGTRANSFER structure for the process that owns the window to which the message is being sent.
In processing the DM_RENDER message, the source window copies the customer details into the shared memory so that when DrgSendTransferMsg() returns, the target window procedure may extract the data it needs. A detailed explanation of the source window's processing of a DM_RENDER message is given in Transferring Information.
Upon completion of the information transfer, the entire drag/drop operation is complete and the data structures allocated during the operation may be released. For the DRAGINFO and DRAGTRANSFER structures, this must be carried out using the DrgFreeDraginfo() and DrgFreeDragtransfer() functions.