Re: Module skinning

> >if you'd like the relevant code, i could upload that for you. if you were
> >thinking of using DROPEFFECT_COPY etc i hear that it's usually
preferrable
> >(more efficient?) to return DROPEFFECT_NONE and use something like
SHFileOp
>
> The main areas I need some info in are moving/copying directories and
moving files from one drive to another.  Copying a file hasn't proven to be
to complicated.
>
> As for the DROPEFFECT_xxxx stuff, that is simply a 'indicator' or a way to
inform the DropSource what type of operation you plan on doing on the data
it is providing.  It does not help any in the actual copy/move/link portion
of the code.  Although, apparently the DropTarget doesn't have to "move" the
data, it just copies it, and the DropSource deletes it's copy, and that
doesn't make much sense to me in a move operation on the same disk.  So I
may be mistaken...  But if you return DROPEFFECT_NONE it will disable the
drag and drop operation I believe, or at the least make the cursor icon
display like it can't drop in your window.
>

yes, it's just an indicator while you're dragging, but once you get to
IDropTarget::Drop then (as you say) returning DROPEFFECT_MOVE would make the
source remove the original file. so (unless the file is locked or something
while it's being dragged ?? i hadn't actually thought of it, but..) in
::Drop you could grab the path from the dropped object and use
SHFileOperation to move the file(s) and then return DROPEFFECT_NONE. so you
should still return DROPEFFECT_MOVE etc while dragging to get the proper
cursor, but then tell the source you didn't do anything when it's dropped
because you handle the move on your own.


anyways, i'll send you what i've got


__________________________________________________
Subscription options and archive:
http://www.freelists.org/list/shell-coding