Fixed CLIP Command Not Working

[Jay Sage]

I wanted to return to the earlier issue of how the clipboards work, specifically when entries get shifted. Instead, I found that the CLIP command no longer works in build 21.

To start, there is a discrepancy in the help information. The help file specifies the following syntax:

CLIP [/C clipn: /R n /S clipn: /Z text]

The error text is different (and contains some square brackets that don't match).

Usage : CLIP [/C n] ]/R n] [/S n text]]

This would imply that just the clipboard number is to be used instead of "clipn:".

In fact, neither syntax works.

TCC(30.00.21): C:\>clip /c clip1:
Usage : CLIP [/C n] ]/R n] [/S n text]]

TCC(30.00.21): C:\>clip /c 1
Usage : CLIP [/C n] ]/R n] [/S n text]]

TCC(30.00.21): C:\>clip /c 1:
Usage : CLIP [/C n] ]/R n] [/S n text]]

TCC(30.00.21): C:\>clip /c1
Usage : CLIP [/C n] ]/R n] [/S n text]]

I get the same error messages when I try "clip /s". The /r option does work with just the number of the clipboard.

 

[Jay Sage]

I'm playing around some more. What is going on here?

TCC(30.00.21): C:\temp>echos junk > clip0:

TCC(30.00.21): C:\temp>clip
CLIP0: 0
CLIP1: 1
CLIP2: 2
CLIP3: 3
CLIP4: 4
CLIP5: 5
CLIP6: 6
CLIP7: 7
CLIP8: 8
CLIP9: 9

Clip0 is not being updated by the redirected output of ECHOS. In general, I am finding very strange behavior with the clipboards. I thought that some of it might have been caused by the presence of my clipboard extension app CLIPX, but I had unloaded it. Strange things continue to happen.

Rex, what is the intended use for these clipboards? It seems that they cannot be used in a batch file for temporary storage because they get rotated (at least sometimes) when new text is copied to the clipboard, even from applications totally outside TCC and Take Command. So far I have been unable to figure out when that happens and when it doesn't.

Now I see different contents in different TCC sessions. Here's one, in which the echo to CLIP0 has finally appeared (and the contents were rotated):

TCC(30.00.21): C:\temp>clip
CLIP0: junk
CLIP1: 0
CLIP2: 1
CLIP3: 2
CLIP4: 3
CLIP5: 4
CLIP6: 5
CLIP7: 6
CLIP8: 7
CLIP9: 8

Meanwhile, in another TCC session, there has been no change.

TCC(30.00.21): C:\>clip
CLIP0:
CLIP1:
CLIP2:
CLIP3:
CLIP4:
CLIP5:
CLIP6:
CLIP7:
CLIP8:
CLIP9:

Now, after clearing the clipboards in two TCC tasks, in one TCC session, I initialized the clipboards. CLIP0 did not get its data.

TCC(30.00.21): C:\temp>clip /z & do i = 0 to 9 (echos %i > clip%i:) & clip
CLIP0:
CLIP1: 1
CLIP2: 2
CLIP3: 3
CLIP4: 4
CLIP5: 5
CLIP6: 6
CLIP7: 7
CLIP8: 8
CLIP9: 9

In another session, the data appeared in CLIP0, but the other clipboards are still empty.

TCC(30.00.21): C:\>clip
CLIP0: 0
CLIP1:
CLIP2:
CLIP3:
CLIP4:
CLIP5:
CLIP6:
CLIP7:
CLIP8:
CLIP9:

 

[Joe Caverly]

Clipboards are static to their respective TCC.

Joe

 

[Joe Caverly]

I use Ditto for my clipboard manager.

This is the batch file that I use to keep Ditto and clip 1-9 in sync.

I run this in each TCC session.

@echo off
@setlocal

COMMENT
I have been using the Ditto Clipboard program
 for a number of years now.

You copy something to the Clipboard,
 and Ditto takes what you copied,
 and stores it in a database to retrieve at a later time.

This .BTM places the last 9 entries from the Ditto.db,
 to the TCC Clipboards 1 to 9.

Call this .BTM before using TCC Clipboards 1 to 9.

TCC Clipboards 1 to 9 only work with text.
 Thus,
 if there is a non-text item on Clipboards 1 to 9,
 it will display as follows when using the CLIP command;

 CLIP4: CF_DIB

Required to run this .BTM;
- TCC 29.00 or higher

- Ditto Clipboard program
  https://github.com/sabrogden/Ditto/wiki

- ISO8601 Plugin
  http://prospero.unm.edu/plugins/iso8601.html

- SQLite3 for reading the Ditto.db
  https://www.sqlite.org/index.html

- (Optional) A RAMDrive
ENDCOMMENT

::
:: Only run this .BTM with TCC Version 29.00 or higher
::
if %_4ver lt 29 quit

BREAKPOINT
::
:: R:\ Drive is a RAMDrive
::
set temp=r:\temp
::
:: This .BTM records the last time it was executed.
::
set lasttime=%@iniread[%_batchname,Main,lasttime]

::
:: Only update if more than 1 minute has passed.
:: Change the wait time to your preference.
::
:: @makeage is a plugin command from ISO8601, not an internal command
::
if %@makeage[%_date,%_time] lt %@eval[%lasttime+1200000000] quit

::set begin=%@makeage[%_date,%_time] && delay 120 && set end=%@makeage[%_date,%_time]

::E:\Utils>echo %begin %end
::133180038640000000 133180039840000000

::E:\Utils>:%end-%begin
::%end-%begin = 1200000000

::
:: Change this to the location of your Ditto.db
::
set dbDitto=C:\Users\jlcav\AppData\Roaming\Ditto\ditto.db

set maxlid=%@execstr[sqlite3.exe %dbditto "select max(lid) from main"]
set minlid=%@eval[%maxlid-8]
set clip=1

do thelid=%minlid to %maxlid
  sqlite3.exe %dbditto "select mtext from main where lid = %thelid" > %temp\%thelid.clip
  type %temp\%thelid.clip > clip%clip:
  set clip=%@eval[%clip+1]
  del /q %temp\%thelid.clip
enddo

::
:: @makeage is a plugin command from ISO8601, not an internal command
::
set lasttime=%@iniwrite[%_batchname,Main,lasttime,%@makeage[%_date,%_time]]

endlocal

quit

[Main]
lasttime=133315814390000000

Joe

 

[Jay Sage]

The default is Clipboards=YES, and that is clearly how my setup is configured, since you see all nine clipboards being written and read.

Clipboards are static to their respective TCC.

I think that my post shows clearly that the statement above is not correct. Changing the clipboard data in one TCC instance causes the contents to change in other instances of TCC. That's exactly the problem I was pointing out. It means that one never knows when a new entry to the Windows clipboard (even totally outside the TCC/TCMD environment) will cause the TCC clipboards to rotate.

I would have wanted the clipboards to be static to the respective TCC instance, including not having the entries rotate unless something was saved to CLIP: in that TCC instance.

 

[vefatica]

Changing the clipboard data in one TCC instance causes the contents to change in other instances of TCC.

CLIP: is, always was, and probably always will be, the good old Windows clipboard. As such, it's not static to any TCC instance. The CLIPn: (n>1) do seem to be per instance, but anybody messing with the good old Windows clipboard will change those per instance values, because of the rotation business. That's just plain bad. You can never be sure what's in any one of of the CLIPn:!

Understanding CLIP: and CLIPn: (as they are) is difficult (and I might have it wrong). The user may avoid using CLIP: or CLIP0: but all the CLIPn: can still change without warning. A good strategy for TCC might be to leave CLIP: completely independent of the CLIPn: (period).

To be honest, I fail to see the value in rotation. The user would have to know it's going to happen and keep track of it! How might rotation be used to advantage?

 

[Jay Sage]

Vince, I agree entirely with what you wrote. Each TCC instance has its own CLIP1-9, but, as you said, they all rotate, so one never knows which clipboard will have what in it.

Even more puzzling to me is why when I write to CLIP: or CLIP0:, sometimes the data is saved and sometimes not. Most bizarre is when it is NOT saved in the TCC instance in which the writing was done but IS stored in another TCC instance.

No one has commented on my statement that the CLIP command with options /C and /S is no longer working. I booted up my laptop and have the same problem there, so I don't think it is peculiar to my setup.

 

[vefatica]

No one has commented on my statement that the CLIP command with options /C and /S is no longer working.

All I can get from /C and /S is CLIP's usage error message.

 

[Jay Sage]

Maybe I shouldn't be asking about this now, since the CLIP command and the clipboards themselves are clearly messed up in the current build.

I've been noticing that I can clear all the clipboards, including number 0, using clip /z. However, when I do that, CLIP shows all the clipboards empty, but if I type clip:, there are contents in the clipboard.

TCC(30.00.21): C:\>clip
CLIP0:
CLIP1:
CLIP2:
CLIP3:
CLIP4:
CLIP5:
CLIP6:
CLIP7:
CLIP8:
CLIP9:

TCC(30.00.21): C:\>type clip:
This is text copied into the clipboard
TCC(30.00.21): C:\>

I just checked this after unloading my CLIPX app that saves a large stack of clips (plus some permanent strings that can be accessed easily). The behavior did not change.

So exactly what is the connection between TCC's clip: and clip0: and the Windows clipboard?

 

[Alpengreis]

Does no more work here too, yep.

 

[rconn]

Understanding CLIP: and CLIPn: (as they are) is difficult (and I might have it wrong). The user may avoid using CLIP: or CLIP0: but all the CLIPn: can still change without warning. A good strategy for TCC might be to leave CLIP: completely independent of the CLIPn: (period).

That would make CLIP1: - CLIP9: useless - might as well just use filenames.

The point of the additional clipboards is if you redirect to CLIP: (or CLIP0:) you will not lose your previous contents of CLIP:, because CLIP0: will be rotated to CLIP1:.

 

[rconn]

I wanted to return to the earlier issue of how the clipboards work, specifically when entries get shifted. Instead, I found that the CLIP command no longer works in build 21.

Fixed in build 22 (typo in the CLIP source code; it wasn't shifting the correct argument to upper case.

This would imply that just the clipboard number is to be used instead of "clipn:".

No - it always requires CLIPn:.

 

[vefatica]

The point of the additional clipboards is if you redirect to CLIP: (or CLIP0:) you will not lose your previous contents of CLIP:, because CLIP0: will be rotated to CLIP1:.

"You" ... do you mean me, I, the user? If I redirect something to CLIP: I expect the old contents to be lost. I can't prevent other apps putting something in CLIP:. If/when they do all my CLIPn: are screwed up and I don't even know it! Rotating those things is bad.

Maybe there needs to be internal variables, _MYCLIP0 ... _MYCLIP9, which tell me where the information **I** put in CLIPn: is now ... or maybe a function, perhaps @WHEREISCLIPNNOW[n].

 

[rconn]

Rex, what is the intended use for these clipboards? It seems that they cannot be used in a batch file for temporary storage because they get rotated (at least sometimes) when new text is copied to the clipboard, even from applications totally outside TCC and Take Command. So far I have been unable to figure out when that happens and when it doesn't.

They are intended to be used when you are writing to the clipboard and want to save the previous clipboard contents.

If you have apps in the background that are also writing to the clipboard (without your knowledge and outside of your control), I would suggest that you don't use the clipboard in TCC. Ever.

 

[rconn]

"You" ... do you mean me, I, the user? If I redirect something to CLIP: I expect the old contents to be lost.

And that's the point of CLIP1: - CLIP9:. Your previous clipboard contents aren't lost anymore.

I can't prevent other apps putting something in CLIP:. If/when they do all my CLIPn: are screwed up and I don't even know it! Rotating those things is bad.

If you have other apps writing to the clipboard, then you can't even trust the contents of CLIP:, so you should probably abandon the clipboard and switch to temporary files.

 

[Jay Sage]

Frankly, an app like CLIPX is a much better solution for saving multiple clipboard entries. One can easily see and access all the entries and can have permanent entries for things one uses often.

I wanted to use the clipboards for temporary storage so that I would not have to work to create (and then delete) unique temporary files and so that I would not have to deal with dimensioning array variables. That is impossible if the clipboards can suddenly rotate (and in my experience that does not always happen immediately, so it is basically unpredictable.

Could we possibly have an option switch for turning off the rotation. Please!

 

[TEA-Time]

Windows 10 and 11 can handle multiple clipboard entries, but you have to enable it in the settings app, then Win+V is the shortcut.

 

[rconn]

Windows 10 and 11 can handle multiple clipboard entries, but you have to enable it in the settings app, then Win+V is the shortcut.

True, but Microsoft has neglected to document an API to access them.

 

[rconn]

Frankly, an app like CLIPX is a much better solution for saving multiple clipboard entries. One can easily see and access all the entries and can have permanent entries for things one uses often.

And do they provide an API so other apps can access the entries?

I wanted to use the clipboards for temporary storage so that I would not have to work to create (and then delete) unique temporary files and so that I would not have to deal with dimensioning array variables. That is impossible if the clipboards can suddenly rotate (and in my experience that does not always happen immediately, so it is basically unpredictable.

Could we possibly have an option switch for turning off the rotation. Please!

Definitely not in CLIPn: - it would be a mangled undocumentable mess.

For what you actually want (temporary files, not clipboards) it would make much more sense to add a new pseudo-device. Something like TMP0: - TMP9:.

 

[vefatica]

Off-topic: Why don't you use AddClipboardFormatListener? It's easier and safer than SetClipboardViewer. Your window simply gets a message. That's it ... no calling next window in the clipboard chain, and no screwing up the clipboard viewer chain if you misbehave.

 

[rconn]

Off-topic: Why don't you use AddClipboardFormatListener? It's easier and safer than SetClipboardViewer. Your window simply gets a message. That's it ... no calling next window in the clipboard chain, and no screwing up the clipboard viewer chain if you misbehave.

TCC does use AddClipboardFormatListener.

 

[vefatica]

TCC does use AddClipboardFormatListener.

Oops! I see. My mistake.

I noticed that TakeCmd.dll imports SetClipboardViewer and not AddClipboardFormatListener. But I failed to notice that TCC.EXE imports AddClipboardFormatListener.

 

[rconn]

TakeCmd.dll imports SetClipboardView for the ClipMonitor command.

 

[vefatica]

Could we possibly have an option switch for turning off the rotation.

It's pretty easy to turn off (BTM at end). In very modest testing it doesn't seem to hurt anything.

v:\> norotate.btm

v:\> do i=0 to 9 ( clip /s clip%i: I am clip %i )

v:\> clip
CLIP0: I am clip 0
CLIP1: I am clip 1
CLIP2: I am clip 2
CLIP3: I am clip 3
CLIP4: I am clip 4
CLIP5: I am clip 5
CLIP6: I am clip 6
CLIP7: I am clip 7
CLIP8: I am clip 8
CLIP9: I am clip 9

v:\> clip /s clip0: The others didn't change.

v:\> clip
CLIP0: The others didn't change.
CLIP1: I am clip 1
CLIP2: I am clip 2
CLIP3: I am clip 3
CLIP4: I am clip 4
CLIP5: I am clip 5
CLIP6: I am clip 6
CLIP7: I am clip 7
CLIP8: I am clip 8
CLIP9: I am clip 9

:: NOROTATE.BTM
setlocal
set wndtitle=TCC:%@lower[%@eval[%_pid=h]]
set hwndTCC=%@winapi[user32.dll,FindWindowW,TCC.EXE,%wndtitle]
set result=%@winapi[user32.dll,RemoveClipboardFormatListener,%hwndTCC]
:: %result == 1 is success; %result == 0 is failure
:: The TCC.EXE class window belonging to this instance
:: will no longer receive WM_CLIPBOARDUPDATE.
:: Here it is as a one-liner (no variables, tested)
:: 1>NUL echo %@winapi[user32.dll,RemoveClipboardFormatListener,%@winapi[user32.dll,FindWindowW,TCC.EXE,TCC:%@lower[%@eval[%_pid=h]]]]

 

[rconn]

Or, you could set Clipboards=no in your TCMD.INI. Which is a bit less drastic.

 

[Jay Sage]

Or, you could set Clipboards=no in your TCMD.INI. Which is a bit less drastic.

From the description of that directive, setting it to no will eliminate the clipboards. That's not what we want. We just want to stop the automatic rotation when new data is saved to the Windows clipboard.

 

[Joe Caverly]

From the description of that directive, setting it to no will eliminate the clipboards. That's not what we want. We just want to stop the automatic rotation when new data is saved to the Windows clipboard.

It would appear that the clipboards are still there,
and that automatic rotation has been stopped,
using that directive.

Indeed, that is how I understood the description as well.

Joe

 

[Joe Caverly]

Hmmm....it would appear that setting Clipboards=No does work,
but when using the CLIP command,
CLIP0: does not show what is actually in that clipboard.

That is,

E:\Utils>echo %_time > clip:

E:\Utils>type clip:
10:42:56

E:\Utils>clip
CLIP0: Clipboards=No

CLIP1:
CLIP2:
CLIP3:
CLIP4:
CLIP5:
CLIP6:
CLIP7:
CLIP8:
CLIP9: E:\Utils\macros.cmd
E:\Utils\macros.cmd.bak

Joe

 

[rconn]

If you set Clipboards=no, you don't have a CLIP0: any more. (If you did, it would rotate.) CLIP1: - CLIP9: are still there, just mostly useless unless all you want is temporary files.

This discussion reminds me of when NT introduced real pipes and 4NT users complained ENDLESSLY that they wanted pipes to be temporary files and not pipes ...

 

[Joe Caverly]

If you set Clipboards=no, you don't have a CLIP0: any more. (If you did, it would rotate.)

Well, we do have CLIP0: when using the @Clip functions;

E:\Utils>echo %@clip[0,0]
10:47:35

E:\Utils>echo %@clipwn[0,Tuesday]
0

E:\Utils>type clip:
Tuesday
E:\Utils>echo %@clip[0,0]
Tuesday

E:\Utils>clip
CLIP0:
CLIP1: 10:47:28
CLIP2:
CLIP3:
CLIP4:
CLIP5:
CLIP6:
CLIP7:
CLIP8:
CLIP9: E:\Utils\macros.cmd
E:\Utils\macros.cmd.bak

E:\Utils>clip /s 0 Again

E:\Utils>type clip:
Again

Joe