Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Copying files (NOT file contents) to clipboard from TCC

Nov
4
0
Is it possible to copy files to the clipboard to paste into applications that accept files (like Windows Explorer, Remote desktop etc).

A specific example - I build a product from a command line prompt resulting in a setup.exe which I then copy and paste into a VMWare session to test. Currently I have to do the build, open Explorer, navigate to the file, select the file and copy it before I can switch to VMware to paste the copied file. I then have to close the file's folder for the next build or Installshield gets upset. If I could copy the file directly to the clipboard using a TCC command it'd cut out a bunch of steps that get really tedious when doing quick build/test cycles. I don't mean copy the contents of the file to the clipboard, I mean copy the file itself. Being able to copy multiple files would be even better so I can automate copying a set of files then paste them into the target.

Mike
 
All you need to do is copy the filename(s) to the clipboard; the target app is responsible for actually doing something with the file(s).

Unless the app is expecting to find a CF_HDROP ?
 
Vince Fatica's 4UTILS plugin has DROPTOCLIP, but it seems to be the inverse of what you want
Code:
E:\>uhelp droptoclip
Convert Explorer-copied files to clipboard filename text
 
I agree that this would be a very useful feature.

MykeJB, would you like to write it up on the uservoice forum? I will happily lend a vote...
 
If I understand this correctly, you want to put into the clipboard what Explorer puts into the clipboard when you highlight a file, right-click, and select "Copy"?
 
Exactly.
I wonder whether it would be possible to do this for *multiple* files. For instance, to copy to the clipboard all jpg files created in the last three days, for pasting into another application:
copytoclip /[dc-3] /T:c /O:t *.jpg
(Assuming TCC's "dir" syntax)
 
According to Noah Coad's Clipboard Viewer, when you select Copy from the Explorer menu, the clipboard is loaded with 12 data formats:
Shell IDList Array
DataObjectAttributes
DataObjectAttributesRequiringElevation
FileDrop
FileNameW
FileName
UIDisplayed
DropDescription
DropEffectFolderList
Shell Object Offsets
Preferred Drop Effect
AsyncFlag
 
Wel, I have a barebones TODROP plugin that basically works (multiple files, too). But I don't have the time to keep working on it now (and probably for a while). I'll post the code below in case anyone (Charles?) :-) wants to play with it. GetArgs() in a wrapper for CommandLineToArgvW() (one could do that with NthArgument()).
Code:
#include <ShlObj.h>
 
INT WINAPI TODROP ( WCHAR *psz )
{
    INT argc;
    WCHAR **argv = GetArgs(psz, &argc);
    WCHAR buf[MAX_PATH];
    WCHAR *pFullNames = (WCHAR*) AllocMem(argc * MAX_PATH * sizeof(WCHAR));
    WCHAR *p = pFullNames;
    for ( INT i=1; i<argc; i++ )
    {
        lstrcpy(buf, argv[i]);
        StripEnclosingQuotes(buf);
        MakeFullName(buf, 0);
        lstrcpy(p, buf);
        p = strend(p)+ 1; // just past the terminating NUL
    }
    *p++ = 0; // now, p is just beyond the double NUL
    DWORD dwDataBytes = sizeof(WCHAR) * (p - pFullNames);
    DROPFILES df = {sizeof(DROPFILES), {0, 0}, 0, TRUE};
    HGLOBAL hMem = GlobalAlloc(GMEM_ZEROINIT|GMEM_MOVEABLE|GMEM_DDESHARE, sizeof(DROPFILES) + dwDataBytes);
    WCHAR *pGlobal = (WCHAR *) GlobalLock(hMem);
    CopyMemory(pGlobal, &df, sizeof(DROPFILES));
    CopyMemory(pGlobal + 10, pFullNames, dwDataBytes); // that's pGlobal + 20 bytes (the size of DROPFILES);
    GlobalUnlock(hMem);
    OpenClipboard(NULL);
    EmptyClipboard();
    SetClipboardData(CF_HDROP, hMem);
    CloseClipboard();
    FreeMem(pFullNames);
    return 0;
}
 
Wel, I have a barebones TODROP plugin that basically works (multiple files, too). But I don't have the time to keep working on it now (and probably for a while). I'll post the code below in case anyone (Charles?) :) wants to play with it. GetArgs() in a wrapper for CommandLineToArgvW() (one could do that with NthArgument()).

I don't expect to have much free time this month, and you're the better programmer anyway. But I can certainly imagine improvements. Like, fr'example, you could use Dir_Cmd to collect filenames; that way you'd get TCC's wildcards, ranges, recursion, etc. for free. Or: I'm no expert on the clipboard, but couldn't you put both CF_HDROP and CF_UNICODETEXT on the clipboard at the same time?
 
I don't expect to have much free time this month, and you're the better programmer anyway. But I can certainly imagine improvements. Like, fr'example, you could use Dir_Cmd to collect filenames; that way you'd get TCC's wildcards, ranges, recursion, etc. for free. Or: I'm no expert on the clipboard, but couldn't you put both CF_HDROP and CF_UNICODETEXT on the clipboard at the same time?
I don't want to get involved in creating the list of files but I'll look into **appending** to an existing CF_HDROP list. That would make it easier for the user to construct the list ... one at a time (say, using DIR as you suggested). In the clipboard's CF_HDROP list, the filename list is NUL-separated (and double-NUL terminated). That wouldn't be particularly useful for CF_UNICODETEXT (would it?). I'll have to read up on putting more than one format in the clipboard. I don't understand the samintz/coad remarks about 12 clipboard formats. If you select/copy with Explorer, there's no text available to be pasted into a text-based app.
 
I did add the capability of appending to a CF_HDROP list to my experimental TODROP.
Code:
v:\> todrop /?
TODROP [/A(ppend)] file [file ...] - files to clipboard in CF_HDROP format
But there is one awkward little detail. It would be convenient to, for example,
Code:
 do file in *.btm ( todrop /a %file )
rather than treating the first file differently. And that's now possible, but it would leave untouched anything previously in a CF_HDROP list. I could add "TODROP /C" to clear the clipboard; it would have to be used separately, before building a list as above (because /C together with /A doesn't make sense). Or I could add separate CLEARCLIP command. Any other ideas?
 
Instead of appending, you might accept the entire list at once from stdin (and e.g. pipe from DIR /B.)
 
Instead of appending, you might accept the entire list at once from stdin (and e.g. pipe from DIR /B.)
This is the first discussion (20+ years) of stuffing things into a clipboard drop list from a command prompt. I really doubt it's going to become an everyday activity. I have this (below) now and I think I'll leave it that way (and leave the fancy stuff to the user). I updated my three major plugins on ftp://lucky.syr.edu/4plugins in case the OP (or anyone) wants to try it.
Code:
v:\> todrop /?
TODROP /C(lear) | [/A(ppend)] file [file ...] - files to clipboard as CF_HDROP
P.S. TODROP is in 4UTILS.
 
This is the first discussion (20+ years) of stuffing things into a clipboard drop list from a command prompt. I really doubt it's going to become an everyday activity.

Oh yeah; definitely an obscure capability. I throw out ideas, but I'm not married to 'em. Please don't interpret my babbling as demands or criticism.
 
I'm imagining an equally useful :-) command,
Code:
EPASTE /C | /M ... destination
which would copy (/C) or move (/M) the files in a clipboard drop list to the specified destination. Internally it would simply call Copy_cmd() or Mv_cmd() (I think that's MOVE) so the "..." could represent any parameters you might supply to COPY or MOVE (but I wouldn't want to check for inappropriate ones!).
 
I'm imagining an equally useful :) command,
Code:
EPASTE /C | /M ... destination
which would copy (/C) or move (/M) the files in a clipboard drop list to the specified destination. Internally it would simply call Copy_cmd() or Mv_cmd() (I think that's MOVE) so the "..." could represent any parameters you might supply to COPY or MOVE (but I wouldn't want to check for inappropriate ones!).
Now 4UTILS provides DROPTOCLIP and TODROP. I would think that those commands are enough to cover all use cases, aren't they? For example:
Code:
DROPTOCLIP && COPY @clip: destination\
would provide EPASTE /C (@clip: N/A in TCCLE).
 

Similar threads

Back
Top