TCC v12 startup questions

[mikea]

Using:
TCC 12.11.71 x64 [Version 6.1.7600] (64-bit under Server 2008 R2)

A search in the forum for 'TCSTART' in titles didn't turn up what I was looking for. Apologies if this has been covered a million times and I just missed it.

I finally upgraded from TCC v11 to v12. Under both versions I have the TCstart/exit path recorded in the Options dialog as C:\TakeCommand, which is where TCC.exe is located. Under both versions I have a TCStart.btm file in C:\TakeCommand. The desktop shortcut for both versions is set to start in that directory as well.

When the desktop shortcut for v11 is launched, TCStart runs. Under v12, it doesn't -- unless the desktop shortcut contains this:

c:\takecommand\tcc.exe /k c:\takecommand\tcstart.btm​

Under v11, it contains only this -- and the command is sufficient to launch TCStart.btm:

c:\takecommand\tcc.exe​

What am I missing here? This kind of command line doesn't appear to be required, per the online help -- if TCStart is located in the directory also containing the command processor.

2nd question: If there's a TCMD.INI in %localappdata\JPSoft and one in the TakeCommand directory where the command processor resides, which of the two takes precedence when TCC loads? TIA...

 

[David Marcus]

2nd question: If there's a TCMD.INI in %localappdata\JPSoft and one in the TakeCommand directory where the command processor resides, which of the two takes precedence when TCC loads?

From the Help: "the search starts in the directory where the Take Command program file is stored. If the .INI file is not found, Take Command will look in the %LOCALAPPDATA% directory."

 

[mikea]

Thanks. Hopefully the first issue mentioned is nothing more than an RTFM problem as well...

 

[mikea]

Thanks. Hopefully the first issue mentioned is nothing more than an RTFM problem as well...

Rex -- any thoughts about this? Some error in how I'm launching the program?

 

[rconn]

> When the desktop shortcut for v11 is launched, TCStart runs. Under v12,
> it doesn't -- *unless* the desktop shortcut contains this:
> c:\takecommand\tcc.exe /k c:\takecommand\tcstart.btm
> Under v11, it contains only this -- and the command is sufficient to

launch

> TCStart.btm:
> c:\takecommand\tcc.exe
> What am I missing here? This kind of command line doesn't appear to be
> required, per the online help -- if TCStart is located in the directory

also

> containing the command processor.

First, make sure you're actually running the TCMD.INI you think you are.
Run OPTION, and see what pathname is in the title bar. Then, try running
"echo %@option[TCStartPath]" and see if TCC thinks there is a "TCStartPath"
in TCMD.INI. (Note that if you also have an old "4StartPath" in TCMD.INI,
it will overwrite TCStartPath.

TCC will look first in the directory specified in TCMD.INI. If it is
defined in TCMD.INI, TCC will *only* look there; if it can't find it, it
will ignore TCSTART.

If it's not defined, TCC will look in COMSPEC. If it's not in COMSPEC, TCC
will look in the root of the boot drive. (This is for compatibility with
old systems; you shouldn't put TCSTART there in newer versions of Windows.)

Rex Conn
JP Software

 

[Charles Dye]

First, make sure you're actually running the TCMD.INI you think you are. Run OPTION, and see what pathname is in the title bar. Then, try running "echo %@option[TCStartPath]" and see if TCC thinks there is a "TCStartPath" in TCMD.INI. (Note that if you also have an old "4StartPath" in TCMD.INI, it will overwrite TCStartPath.

Or forget about the .INI file and just use OPTION to configure the program; that's what it's for. (I would not be at all surprised if some future version of Take Command just did away with the .INI altogether and moved everything into the registry....)

 

[mikea]

I looked over the setup again...

TCC and all the trimmings are in C:\TakeCommand.

There was originally a TCMD.INI file in \users\mikea. I renamed it to TCMD.INI.OLD.

There is a TCMD.INI file in C:\TakeCommand.

According to OPTION, the TCstart/TCExit Path is "C:\TakeCommand" (which is the location of TCStart.btm). In the OPTION dialog box, that location appears in both the title bar and the TCStart/TCExit text field.

The command "echo %@option[TCStartPath]" echoes "C:\TakeCommand".

The command "echo %comspec" echoes "C:\TakeCommand\TCC.EXE".

After checking all of the above I found that C:\TakeCommand\TCMD.INI did contain a "4StartPath" entry. I removed the 4StartPath line. For good measure I ran "Shralias /u". I closed the TCC window, then launched TCC again via the desktop shortcut. Once again TCC launched without running TCStart.btm.

Once again I had to add "/k c:\takecommand\tcstart.btm" to the command in the desktop shortcut to get TCStart to launch.

So ... what should I try next?

Thanks.

launch
also
First, make sure you're actually running the TCMD.INI you think you are.
Run OPTION, and see what pathname is in the title bar. Then, try running
"echo %@option[TCStartPath]" and see if TCC thinks there is a "TCStartPath"
in TCMD.INI. (Note that if you also have an old "4StartPath" in TCMD.INI,
it will overwrite TCStartPath.

TCC will look first in the directory specified in TCMD.INI. If it is
defined in TCMD.INI, TCC will *only* look there; if it can't find it, it
will ignore TCSTART.

If it's not defined, TCC will look in COMSPEC. If it's not in COMSPEC, TCC
will look in the root of the boot drive. (This is for compatibility with
old systems; you shouldn't put TCSTART there in newer versions of Windows.)

Rex Conn
JP Software

 

[mikea]

This isn't about how options are configured. It's about getting TCStart to run when TCC itself is launched.

Doing away with the .INI file might occasionally push users into the position of having to muck around in the Registry. I don't think that's the user-friendliest approach. INI files are simple, don't take up any space to speak of, and are quick 'n' easy to edit, when need be.

Or forget about the .INI file and just use OPTION to configure the program; that's what it's for. (I would not be at all surprised if some future version of Take Command just did away with the .INI altogether and moved everything into the registry....)

 

[vefatica]

On Wed, 27 Jul 2011 22:40:30 -0400, mikea <> wrote:

|This isn't about how options are configured. It's about getting TCStart to run when TCC itself is launched.
|
|Doing away with the .INI file might occasionally push users into the position of having to muck around in the Registry. I don't think that's the user-friendliest approach. INI files are simple, don't take up any space to speak of, and are quick 'n' easy to edit, when need be.

I think Charles meant that the OPTION dialog does edit TCMD.INI; it's the
preferred way. I reckon 99% of what's in (or could be in) TCMD.INI can be
set/changed in the OPTION dialog.

 

[rconn]

Make sure you don't have any (obsolete) "4START.*" / "4EXIT.*" files still
hanging around.

And make sure you haven't disabled .BTM files (i.e., with something like a
PATHEXT in your environment). You could try renaming TCSTART.BTM to
TCSTART.CMD to see if that runs.

Rex Conn
JP Software

 

[mikea]

I think Charles meant that the OPTION dialog does edit TCMD.INI; it's the
preferred way. I reckon 99% of what's in (or could be in) TCMD.INI can be
set/changed in the OPTION dialog.

Understood.

This was a case in which using OPTION did not sufficiently edit the .INI file. Somehow a "4start" key got in there and had to be removed manually. I would really not have wanted to have to do a thing like that via regedit. In any case, how the options get set up is kind of side-issue at the moment. Despite the removal of the "4start" key, TCStart still won't launch on that machine in the way it does on the other (Win 7) machine.

Could it be some weird Win7 vs Server 2008 issue? But no... that machine (pre-crash) was running Server. At the time it had 4NT v5 on it, and there was no need for me to use "/k c:\4nt5\4start.btm" in the shortcut. But (for now) I do have to use "/k c:\takecommand\tcstart.btm" in the TCC shortcut.

 

[mikea]

Make sure you don't have any (obsolete) "4START.*" / "4EXIT.*" files still
hanging around.

And make sure you haven't disabled .BTM files (i.e., with something like a
PATHEXT in your environment). You could try renaming TCSTART.BTM to
TCSTART.CMD to see if that runs.

Rex Conn
JP Software

No 4*.btm files hanging around (they are all renamed). I added '.BTM' to %pathext% -- the global variable for it -- and then the .BTM file launched just fine. But I don't think I want cmd.exe trying to launch .BTM files -- that'll be a big exercise in frustration. So I guess the thing needs to be TCStart.cmd (not .btm).

 

[rconn]

> No 4*.btm files hanging around (they are all renamed). I added
> '.BTM' to %pathext% -- the global variable for it -- and then the
> .BTM file launched just fine. But I don't think I want cmd.exe
> trying to launch .BTM files -- that'll be a big exercise in frustration.
> So I guess the thing needs to be TCStart.cmd (not .btm).

TCC doesn't care about the extension -- it can be TCSTART.BTM, TCSTART.CMD,
TCSTART.BAT, or even TCSTART.EXE.

Rex Conn
JP Software

 

[mikea]

TCC doesn't care about the extension -- it can be TCSTART.BTM, TCSTART.CMD,
TCSTART.BAT, or even TCSTART.EXE.

.cmd works for me. Better that, than use pathext in the global environment to make cmd.exe think it can run .btm files. (This must be a Server 2008 'thing'; it hasn't been an issue at all with Win 7.)

Thanks.

 

[thedave]

On 7/24/2011 6:12 PM, Charles Dye wrote:

> Or forget about the .INI file and just use OPTION to configure the program; that's what it's for. (I would not be at all surprised if some future version of Take Command just did away with the .INI altogether and moved everything into the registry....)

While I'm okay with that in general, I also use multiple machines and
enjoy the ability to quickly deploy a new machine and have my familiar
configuration show up.

INIs are the easiest way to accomplish this, registry stuff isn't that
difficult either.

Using OPTION to manually set a bunch of options isn't particularly
useful in this scenario.

 

[mikea]

An .INI or .XML config file does make that kind of transfer to multiple machines pretty easy. I suppose you could do the export/import thing from/to the Registry, but just dropping the .INI file in the right directory is easier yet. Not that using OPTION is especially difficult, but it could be a bit time-consuming (retyping 'dircolor' instructions, for instance).

While I'm okay with that in general, I also use multiple machines and
enjoy the ability to quickly deploy a new machine and have my familiar
configuration show up.

INIs are the easiest way to accomplish this, registry stuff isn't that
difficult either.

Using OPTION to manually set a bunch of options isn't particularly
useful in this scenario.