Welcome!

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

SignUp Now!

tcmd clearing clipboard

Jun
4
0
Hi there,
I'm getting a very regular issue with tcmd clearing the clipboard ( and sometimes inserting random single characters instead ). I've had this for a while, but I'm afraid I couldn't say since which version as at first I thought it was either just me going insane or having a very strange ability to fail to press <ctrl>-c <ctrl>-v properly.

My current version is TCC 12.11.76 x64 Windows 7 [Version 6.1.7601]

It appears to only be when copying from an explorer window and switching to tcmd.

I've traced it to tcmd by using a clipboard viewer, finding the HWND owner of the clipboard at the time of clearing, and then the process ID, which points to tcmd.exe.

It doesn't matter if I am trying to copy the full path, or part of the path, tcmd will just randomly obliterate it.

Anyone have any ideas?
 
Can you give us some steps to follow in trying to reproduce the problem?

On Tue, 01 Nov 2011 14:54:40 -0400, lemooseigh <> wrote:

|Hi there,
| I'm getting a very regular issue with tcmd clearing the clipboard ( and sometimes inserting random single characters instead ). I've had this for a while, but I'm afraid I couldn't say since which version as at first I thought it was either just me going insane or having a very strange ability to fail to press <ctrl>-c <ctrl>-v properly.
|
|My current version is TCC 12.11.76 x64 Windows 7 [Version 6.1.7601]
|
|It appears to only be when copying from an explorer window and switching to tcmd.
|
|I've traced it to tcmd by using a clipboard viewer, finding the HWND owner of the clipboard at the time of clearing, and then the process ID, which points to tcmd.exe.
|
|It doesn't matter if I am trying to copy the full path, or part of the path, tcmd will just randomly obliterate it.
|
|Anyone have any ideas?
 
All I need to do is
boot up tcmd
open an explorer window to any where ( local drives, windows share
copy all or part of the address in the address bar ( I alt-d and ctrl-c/ctrl-x )
alt-tab to tcmd
ctrl-v

Here, more often than not, is where the clipboard is trashed.

Using the context menu to copy/paste also fails at the same rate, and the same issue occurs if copying from internet explorer.

This only appears to occur from explorer/IE.
It doesn't appear to happen if I switch to another application before switching to tcmd (unless it's another explorer/IE window I switch to ).
It also doesn't happen when I copy from another app and switch to tcmd.


Can you give us some steps to follow in trying to reproduce the problem?
 
TCC 12.11.76 x64 Windows 7 [Version 6.1.7600]
TCC Build 76 Windows 7 Build 7600

I can not reproduce what you report.

On Tue, Nov 1, 2011 at 12:56, lemooseigh <> wrote:


> All I need to do is
> boot up tcmd
> open an explorer window to any where ( local drives, windows share
> copy all or part of the address in the address bar ( I alt-d and
> ctrl-c/ctrl-x )
> alt-tab to tcmd
> ctrl-v
>
> Here, more often than not, is where the clipboard is trashed.
>
> Using the context menu to copy/paste also fails at the same rate, and the
> same issue occurs if copying from internet explorer.
>
> This only appears to occur from explorer/IE.
> It doesn't appear to happen if I switch to another application before
> switching to tcmd (unless it's another explorer/IE window I switch to ).
> It also doesn't happen when I copy from another app and switch to tcmd.
>
>
>
> ---Quote (Originally by vefatica)---
> Can you give us some steps to follow in trying to reproduce the problem?
> ---End Quote---
>
>
>
>



--
Jim Cook
2011 Monday: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Tuesday.
 
On Tue, 01 Nov 2011 19:30:10 -0400, rconn <> wrote:

|Not reproducible here.

I can't reproduce it either.

But I did notice simething very interesting. If, in Explorer, I select a file
or directory, open the right-click context menu and choose "Copy" ... then go to
TCMD, I **can** (the interesting part) paste the file/dir **full name** into the
command line with right-click context menu\paste. At the same time consoles and
other apps expecting text in the clipboard see it as empty.

So TCMD's right-click\paste is doing something nice ... maybe recognizing
muliple formats in the clipboard or otherwise being smart enough to get the file
name and paste it. It would be nice if TCC could do that.

Note, it even works if multiple files/dirs are so selected ... they're pasted to
the command line in TCMD separated by spaces
 
So TCMD's right-click\paste is doing something nice ... maybe recognizing
muliple formats in the clipboard or otherwise being smart enough to get the file
name and paste it. It would be nice if TCC could do that.

Note, it even works if multiple files/dirs are so selected ... they're pasted to
the command line in TCMD separated by spaces

TCMD is doing a *LOT* of work to handle all of that.

Unfortunately, it's impossible in a stand-alone console app, because Windows won't pass the necessary mouse messages. Another reason to be running TCMD!
 
On Tue, 01 Nov 2011 21:26:32 -0400, rconn <> wrote:

|Unfortunately, it's impossible in a stand-alone console app, because Windows won't pass the necessary mouse messages. Another reason to be running TCMD!

I understand that you can't get the *console* to cooperate. But couldn't you
implement it (future version) for Ctrl-V, @CLIP[], @LINES[clip:], and
@LINE[clip:,n]? I imagine it could go something like this (not a heck of a lot
of work?).

If no clipboard text format is available, check for CF_HDROP; that's what the
shell uses for a collection of files "copied" via the right-click context menu.
If CF_HDROP is available, you can get the file count and names pretty easily,
like this.

Code:
WCHAR szFileName[MAX_PATH];
HDROP hDrop = (HDROP) GetClipboardData(CF_HDROP);
if ( hDrop != NULL )
{
	UINT nFiles = DragQueryFile(hDrop, 0xFFFFFFFF, NULL, 0);
	for ( INT i=0; i<nFiles; i++ )
	{
		DragQueryFile(hDrop, i, szFileName, MAX_PATH);
		wprintf(L"%s\n", szFileName);
	}
}

My personal preference would be that @LINES[clip:] count the files, @CLIP[n] and
@LINE[clip:,n] return them separately, but Ctrl-V give them all, space separated
and quoted. I didn't much like TCMD's pasting them **newline-separated** after
"Copy as path"; they're space-separated if copied in Explorer and pasted into
TCMD.
 
<nfiles; i++="" )
When I view my previous message on the forum, the "code" segment terminates after "for ( INT i=0; i" (no doubt because of the LT symbol next). But when I quote that post the quoted text includes all the code except only for the tail of the "for" line ... odd ... a bug?

Anyway, here's the code again.

</nfiles;>
Code:
OpenClipboard(NULL);
WCHAR szFileName[MAX_PATH];
HDROP hDrop = (HDROP) GetClipboardData(CF_HDROP);
if ( hDrop != NULL )
{
    UINT nFiles = DragQueryFile(hDrop, 0xFFFFFFFF, NULL, 0);
    for ( INT i=0; i LT nFiles; i++ )
    {
        DragQueryFile(hDrop, i, szFileName, MAX_PATH);
        wprintf(L"%s\n", szFileName);
    }
}
CloseClipboard()
<nfiles; i++="" )


Even though an error message is not in order when the clipboard contains nothing of interest, it's worth noting that if GetClipboardData() (as above) fails (CF_HDROP not available), GetLastError() will return 0.


</nfiles;>
 
TCMD is doing a *LOT* of work to handle all of that.

Unfortunately, it's impossible in a stand-alone console app, because Windows won't pass the necessary mouse messages. Another reason to be running TCMD!

If the data is already in the clipboard, why do you need mouse messages?

-Scott
 
Vince,

If it's that simple, you could create a plug-in command that converts the
clipboard contents from CF_HDROP to CF_TEXT. Then all the rest of the
regular clip: tools should just work.

-Scott



When I view my previous message on the forum, the "code" segment
terminates after "for ( INT i=0; i" (no doubt because of the LT symbol
next). But when I quote that post the quoted text includes all the code
except only for the tail of the "for" line ... odd ... a bug?

Anyway, here's the code again.

Code:
OpenClipboard(NULL);
WCHAR szFileName[MAX_PATH];
HDROP hDrop = (HDROP) GetClipboardData(CF_HDROP);
if ( hDrop != NULL )
{
UINT nFiles = DragQueryFile(hDrop, 0xFFFFFFFF, NULL, 0);
for ( INT i=0; i LT nFiles; i++ )
{
DragQueryFile(hDrop, i, szFileName, MAX_PATH);
wprintf(L"%s\n", szFileName);
}
}
CloseClipboard()


Even though an error message is not in order when the clipboard contains
nothing of interest, it's worth noting that if GetClipboardData() (as
above) fails (CF_HDROP not available), GetLastError() will return 0.
 
On Thu, 03 Nov 2011 13:25:05 -0400, samintz <> wrote:

|Vince,
|
|If it's that simple, you could create a plug-in command that converts the
|clipboard contents from CF_HDROP to CF_TEXT. Then all the rest of the
|regular clip: tools should just work.

Yes, but how would it be used? It would have to be cumbersome. Copy/paste is
usually done on-the-fly. If I were composing a command and wanted to paste,
say, a space-separated list of file names copied in Explorer, I couldn't execute
a command. I suppose I could implement a variable, say, _HDROP that would
return such a list. But being seamlessly built into all the clipboard features
provided by TCC seems much nicer.
 
Well, alternatively, you could make it a stand-alone application that gets
invoked via hot-key. Say Ctrl+Alt+V.
-Scott




On Thu, 03 Nov 2011 13:25:05 -0400, samintz <> wrote:

|Vince,
|
|If it's that simple, you could create a plug-in command that converts the

|clipboard contents from CF_HDROP to CF_TEXT. Then all the rest of the
|regular clip: tools should just work.

Yes, but how would it be used? It would have to be cumbersome. Copy/paste
is
usually done on-the-fly. If I were composing a command and wanted to
paste,
say, a space-separated list of file names copied in Explorer, I couldn't
execute
a command. I suppose I could implement a variable, say, _HDROP that would
return such a list. But being seamlessly built into all the clipboard
features
provided by TCC seems much nicer.
 
On Thu, 03 Nov 2011 14:54:43 -0400, samintz <> wrote:

|Well, alternatively, you could make it a stand-alone application that gets
|invoked via hot-key. Say Ctrl+Alt+V.

That could be done by a plugin keystroke handler. And I suppose I could do
@DROP[n] = count (n=0) or = the line itself (n=1 to count).
 

Similar threads

Back
Top