Fixed CLIP Command Not Working

[Charles Dye]

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 ...

I'm still waiting for you to ditch the .INI file and move all the settings into the registry, so we can complain endlessly about that....

 

[Joe Caverly]

Using;

E:\Utils>clip /s 0 Again

E:\Utils>type clip:
Again

...does update the output of CLIP for Clip0;

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

@clipwn does not update the output of CLIP for Clip0;

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

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

Joe

 

[vefatica]

Does option //Clipboards=No work on-the-fly? After using it I still see the rotation.

 

[vefatica]

@clipwn does not update the output of CLIP for Clip0;

It does here. I have Clipboards=No in _ininame.

v:\> clip /s clip0: bar

v:\> clip | head /n 3
CLIP0: bar
CLIP1: foo
CLIP2:

v:\> echo %@clipwn[0,foobar] > NUL

v:\> clip | head /n 3
CLIP0: foobar
CLIP1: foo
CLIP2:

 

[Jay Sage]

If you set Clipboards=no, you don't have a CLIP0: any more.

I agree with Joe. I have set the directive to No. All the clipboards are still there, and I can write to them and read from them, including clip: and clip0:. The only thing that has changed is that the data does not rotate into the other clipboards.

TCC(30.00.22): C:\>option clipboards
clipboards=No

TCC(30.00.22): C:\>do i=0 to 9 ( clip /s clip%i: I am clip %i ) & clip
CLIP0: I am clip 0
CLIP1: I am clip 1
CLIP2: I am clip 2
...

TCC(30.00.22): C:\>clip /s clip0: New data in clip 0 & clip
CLIP0: New data in clip 0
CLIP1: I am clip 1
CLIP2: I am clip 2
...

This is exactly the behavior that I (and Vince) were asking for and that you said was not possible. When I wrote: "Could we possibly have an option switch for turning off the rotation. Please!", your answer was:

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

 

[Jay Sage]

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

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.

As far as I can tell, clip: and clip0: are fully functional with the clipboards option set to No. Clip: gets updated

 

[Jay Sage]

One correction: with the clipboards option set to No, the command

clip /s clip: text

generates an error message and does not write the text to the clipboard. However, very strangely,

clip /s clip0: text

does work and does send the text to the Windows clipboard!

 

[Jay Sage]

Rex, what do the following commands do:

option //clipboard=No
option //clipboard=Yes

The value as reported by option clipboards changes, but the behavior of TCC does not change. In fact, the option-changing commands seem to have no effect at all. Even after closing TCMD and relaunching it, everything is back to the way it was. The INI file was not updated.

 

[rconn]

Rex, what do the following commands do:

option //clipboard=No
option //clipboard=Yes

The value as reported by option clipboards changes, but the behavior of TCC does not change. In fact, the option-changing commands seem to have no effect at all. Even after closing TCMD and relaunching it, everything is back to the way it was. The INI file was not updated.

That option determines whether TCC registers itself for clipboard notifications. It is only referenced at startup.

 

[Jay Sage]

So, are you saying that there is no point to issuing the option //clipboards= command, that the only way to change the setting is to edit the INI file? That's fine, of course, but it would be nice if it were documented.

Is it documented anywhere which options can and cannot be changed by the OPTION command, which changes get written to the INI file, and which one take effect immediately and which one only on startup? I think that some changes do get written to the INI file when Take Command is closed, because I had the INI file open in V and was notified that the file had changed.

 

[rconn]

Take Command does not write any user-configurable .INI variables when it shuts down. It does write a few undocumented settings for its own use, but if you try to modify those bad things will happen.

 

[Jay Sage]

OK, that explains why V reported a change in the INI file.

However, that leaves my question about the documentation of which option settings take effect in the current session and which ones really should never be used with the option //setting=value command. (It would be nice, in fact, if such a command line would throw an error message when the setting cannot be changed on the fly.)

By trial and error I discovered that, fortunately, the email settings used by SENDHTML can be changed on the fly. I currently set those options in my TCSTART script to make sure that my default setting is restored. From what you say above, I needn't do that; changes made on the fly will not affect a new TCC task.

 

[rconn]

All the options can be changed at any time. But a couple of them (like Clipboards) only affect startup & shutdown.

The only supported way of modifying .INI settings is using the OPTION dialog. Anything that isn't in the OPTION dialogs shouldn't be set by end users unless you're quite sure you know what you're doing. I am not going to document the many ways that you can obliterate your system.