Shortcut stops working after 4NT to TCC Upgrade

[vefatica]

This thread has been hard to follow. Has the OP tried this ...

Start TCC. CDD to the directory containing the shortcut. Verify, with DIR,
that TCC can **see** the shortcut. Use the SHORTCUT command. Like this:

v:\> cdd e:\Users\vefatica\Desktop\

e:\users\vefatica\desktop> dir /k /m *.lnk
2011-05-23  10:54             375  avetemp2.btm.lnk

e:\users\vefatica\desktop> shortcut avetemp2.btm.lnk
Command=V:\avetemp2.btm
ArgumentsDirectory=V:\
DescriptionLink=avetemp2.btm.lnk
IconOffset=0
Mode=1
Hotkey=

 

[NickCupery]

Okay, I'm back after having carefully perused all your comments, and here are
some responses:

To Charles Dye, who said "Try the file TCCHERE.BTM...", I say THANK YOU! I'd
never heard of that one, and I sure am grateful to have it. (Um, Rex, the
install process really should ASK about stuff like "TCC Here". I realize I'm about
to be accused of failure to RTFM, but really...)

To Steve Fabian, I say no way, no how, do I ever run with anything hidden, including file-extensions and Hidden/System files. It was a decent guess though, and I thank you for trying to help me.

To Vince, who pointed out that Windows hides the .LNK and .URL extensions
NO MATTER WHAT, I say THANK YOU. I never gnu that, but it sure explains
a lot. (Also makes me slightly nauseous, Microsoft...)

To David Marcus, who said "Instead of telling us what you did, cut and paste...",
I say THANK YOU. I could never figure out how to cut and paste from a 4DOS
console window (if that was even possible), so I never tried it again. This time,
you goaded me into trying harder and it worked! I still have no idea what "Mark"
is supposed to do for me (right-click menu), but it turns out that "Select All" puts
the whole shebang into the clipboard. (Yes, I plan to RTFM more on this.)

Anyway, now knowing that the system LIES about the name of the shortcut,
and now knowing how to cut and paste from a TCC console window, here is
the verbatim result of the Shortcut command run on my errant .BTM file
<after all this, there really should be a drumroll here>:

C:\Documents and Settings\ENCupery\Desktop>shortcut testtcc.btm.lnk
Command=F:\Backup\testtcc.btm
Arguments=J
Directory=F:\Backup
Description=
Link=testtcc.btm.lnk
Icon=
Offset=0
Mode=1
Hotkey=

So, is this batch file a winner or a loser?

I have more to say on this, but I'll stick it in a separate message because I
have a lot of typing at risk here.

-- Nick

 

[NickCupery]

I have boiled down my Archive.btm to a much smaller one that exhibits the same
errant behavior. I named this one TestTCC.btm and I placed it in my F:\Backup\
directory:

--------------------------------------------------------------------------
@REM F:\BACKUP\TESTTCC.BTM 24-May-11 07:48:32am
@VER

@IF DIREXIST %1:\ goto YES
@ECHO ERROR -- Drive %1 does not exist
@GOTO END

:YES
@ECHO Okay

:END
@DELAY 2
--------------------------------------------------------------------------

Here is the sequence of experiments I ran (and you could hopefully duplicate)
using TestTCC.btm:

First, I opened a TCC console window and changed my working directory
to F:\Backup\ and typed "TestTCC". The result, as expected, was
(note the double space between "Drive" and "does"):

----------------------------------------------------------
F:\Backup>testtcc

TCC 12.10.61 Windows XP [Version 5.1.2600]
ERROR -- Drive does not exist

F:\Backup>
----------------------------------------------------------

Then, I typed "TestTCC J", and the result, as expected, was:

-----------------------------------------------------------
F:\Backup>TestTCC J

TCC 12.10.61 Windows XP [Version 5.1.2600]
ERROR -- Drive J does not exist

F:\Backup>
-----------------------------------------------------------

This last result was as expected, because there really was no Drive J
at the time. Please take my word for it when I say that when I do
plug in Drive J, then the result of the above experiment is "Okay".
The whole point here is that the batch file does correctly handle and
interpret the %1 argument.

For my next trick, I right-dragged TestTCC.btm onto the desktop, and
selected "Create Shortcuts Here" from the popup context menu. Windows
created a shortcut named "TestTCC.btm", the properties for which showed
a Target of "F:\Backup\TestTCC.btm" and a Start directory of "F:\Backup".
When I double-clicked on this shortcut, I got the expected result:

----------------------------------------------------------
F:\Backup>testtcc

TCC 12.10.61 Windows XP [Version 5.1.2600]
ERROR -- Drive does not exist

F:\Backup>
----------------------------------------------------------

Next, I opened up the properties page for the shortcut again, and added the
drive letter J to the Target line, so that it said "F:\Backup\TestTCC.btm J".
When I then double-clicked on the shortcut, I got the EXACT SAME result as
above. IOW, the parameter "J" is NOT getting passed to the batch file as
the %1 argument. Remember, I claim this all worked fine for years, with
both 4DOS and 4NT. It just does not work with TCC. (Furthernore, I tried
this on my new Windows 7 Professional 64-bit laptop, using TCMD/TCC x64,
and it DOES NOT WORK THERE EITHER.)

Anyone who can explain/fix this problem could be a hero.

-- Nick

 

[Charles Dye]

When I try to replicate this, I get an "Okay" message (J: is a valid network drive here.) If I change the J to a Q, I see "Drive Q does not exist", as expected.

Something funky is going on with your file association. What do you see if you paste and run this ...?

echo %@regquery[HKCU\Software\Classes\.btm\]

 

[David Marcus]

I still have no idea what "Mark" is supposed to do for me (right-click menu)

That's Windows for you. Do Mark. Then use the cursor keys to move to the start of the text. Then hold down Shift and use the cursor keys to move to the end. Press Enter.

Under Properties > Options > Edit Options, you can select QuickEdit Mode, which lets you use the mouse.

It is easier if you are running in a Take Command tab. See "Highlighting & Copying Text" in the Help. Also see the "Linux-style Selection" option.

 

[Charles Dye]

Um, Rex, the install process really should ASK about stuff like "TCC Here". I realize I'm about to be accused of failure to RTFM, but really...)
<after all="" this,="" there="" really="" should="" be="" a="" drumroll="" here="">

On the subject of Windows shell integration: Yes, this kind of thing might be better done, optionally, by the installer. Also: (1) create default Edit and Print verbs for .BTM files (copy from cmdfile, or just assume Notepad; (2) create a Debug verb for .BTM / .BAT / .CMD files; (3) add TCC.EXE and/or TCMD.EXE to AppPaths; (4) create a .BTM file template.

</after>

 

[rconn]

On the subject of Windows shell integration: Yes, this kind of thing might be better done, optionally, by the installer. Also: (1) create default Edit and Print verbs for .BTM files (copy from cmdfile, or just assume Notepad; (2) create a Debug verb for .BTM / .BAT / .CMD files; (3) add TCC.EXE and/or TCMD.EXE to AppPaths; (4) create a .BTM file template.

</AFTER>

That used to be done by the installer, and I got hundreds of complaints about it, even as options. That's why it's now done by batch files (which *is* documented).

I don't see the point in #3, since nobody other than Explorer and TCC ever use AppPaths. (And it has always been a support headache when people are executing a different version than they think they are.)

I don't understand what you want with #4.

 

[vefatica]

On Tue, 24 May 2011 09:17:49 -0400, NickCupery <> wrote:

|--------------------------------------------------------------------------
|@REM F:\BACKUP\TESTTCC.BTM 24-May-11 07:48:32am
|@VER
|
|@IF DIREXIST %1:\ goto YES
|@ECHO ERROR -- Drive %1 does not exist
|@GOTO END
|
|:YES
|@ECHO Okay
|
|:END
|@DELAY 2
|--------------------------------------------------------------------------

I used that exact BTM file (since my first available drive letter is "J") and it
worked as expected, with the error whenever the WD external drive was not
plugged in and "Okay" when it was plugged in.

You might add to the BTM file, at the beginning,

@ECHO %%1 is **%1**

When I do that I see

%1 is **J**

regardless of whether the drive is plugged in.

 

[Charles Dye]

That used to be done by the installer, and I got hundreds of complaints about it, even as options. That's why it's now done by batch files (which *is* documented).

I hear you... These are all just brain farts, not requests.

I don't see the point in #3, since nobody other than Explorer and TCC ever use AppPaths.

I like to be able to type TCC in the Start/Run dialog to launch TCC.EXE, just as I would type CMD to start that other shell. Perhaps I'm the only one. (All of your hardcore users are weird.)

I don't understand what you want with #4.

Another tweak that probably only a few hardcore nerds would use: the ability to right-click in an Explorer window and New / "Take Command batch file" to create a .BTM. Basically you create a minimal file in %windir\ShellNew (mine is just two lines, @ECHO OFF and SETLOCAL), and add a pointer to it in HKCR\.btm\ShellNew\Filename. Again, something I like but maybe everyone else would hate.

Another thought: TCCBATCH.BTM might check for a user-level file association for .BTM files and, if found, offer to delete it; or at least notify the user that it exists. (I have a hunch this is NickCupery's issue.)

 

[vefatica]

On Tue, 24 May 2011 11:16:57 -0400, vefatica <> wrote:

|You might add to the BTM file, at the beginning,
|
|
|Code:
|---------
|@ECHO %%1 is **%1**
|---------
|When I do that I see

Sorry, I didn't read carefully ... you already did essentially that.

If you have an extension (say, .CMD) still associated with CMD.EXE, you could
try the same test with a shortcut to a .CMD file. This might work.

@REM TESTCMD.CMD
@echo off
if exist %1:\ echo %1 ... YES
if not exist %1:\ echo %1 ... NO
for /l %%i in (1,1,1000000) do set a=a

The last line keeps the console open for a while. If the shortcut does not
supply the "J" to the CMD file, you'll see errors.

 

[Steve Fabian]

From: NickCupery
| I have boiled down my Archive.btm to a much smaller one that exhibits
| the same errant behavior. I named this one TestTCC.btm and I placed
| it in my F:\Backup\ directory:
|
| --------------------------------------------------------------------------
| @REM F:\BACKUP\TESTTCC.BTM 24-May-11 07:48:32am
| @VER
|
| @IF DIREXIST %1:\ goto YES
| @ECHO ERROR -- Drive %1 does not exist
| @GOTO END
|
| :YES
| @ECHO Okay
|
| :END
| @DELAY 2

Here is a functionally identical, but more JPsoft-styled version:
--- start code ---
@echo off
REM F:\BACKUP\TESTTCC.BTM 2011-05-24 12:21
VER
iff %# LT 1 then
echo No drive specified in command line - quitting
else
echo Drive %1 is %@if[%@ready[%1:] EQ 0,not,] ready
endiff
delay 2
--- finish code ---

BTW, all of the features used above date back to 4NT.
--
Steve

 

[NickCupery]

To Charles Dye, who said "Something funky is going on with your file association",
I reply "Amen to that!". When I run the command you suggested, on my
Win XP Pro SP3 system, I get:

-----------------------------------------------------------------
F:\NICK>echo %@regquery[HKCU\Software\Classes\.btm\]
-1

F:\NICK>
-----------------------------------------------------------------

However, when I run the same command on my Win 7 Pro x64 system, I get
the answer "btm_auto_file" (without the quotes). So, is either of those two
results either good or bad? (Remember, I have the SAME "missing argument"
problem on BOTH machines.)

And, Charles, thanks for being on my side when it comes to thinking the
installation program should ASK about the file-associations, etc. although
I have no need for your (3) or (4) suggestions. I see from Rex's reply that
we ain't gonna get any of it anytime soon. Imaging my total surprise to learn
that Rex has encountered difficulty attempting to please all of the users all of
the time. HAHA!

Finally, Charles, I'm wondering what you meant when you suggested that
my problem might be associated with "a user-level file-association for .BTM".
What is meant by "user level"? Are there other levels? What are their names?

Thanks to David Marcus for the explanation of "Mark" (mind-boggling as it is).
I decided to give the "QuickEdit Mode" a try, and that seems a lot easier. I do
realize that I need to RTFM about this QuickEdit Mode, but I must say that my
initial impression is that TCC seems to totally waste the right mouse button.
I was surprised to NOT see a popup context menu with a zillion options, one
of which was "copy". Oh well, I'm starting to think it's not a perfect world.

-- Nick

 

[Charles Dye]

-----------------------------------------------------------------
F:\NICK>echo %@regquery[HKCU\Software\Classes\.btm\]
-1

F:\NICK>
-----------------------------------------------------------------

However, when I run the same command on my Win 7 Pro x64 system, I get the answer "btm_auto_file" (without the quotes). So, is either of those two results either good or bad? (Remember, I have the SAME "missing argument" problem on BOTH machines.)

There are two similar-but-different ways of doing file associations: a per-user method, which only affects the current users, and a systemwide method, which affects all users. I was thinking that you could have a good file-to-open-command mapping in the systemwide method (thanks to TCCBATCH.BTM) and a broken mapping in the per-user method (probably thanks to Explorer), and that would explain the results you're seeing. ASSOC and FTYPE would report the good, systemwide mapping, whereas Explorer would use the broken per-user settings.... Now I'm confused; only your x64 results are what I'd expect to see.

But anyway, it should be harmless to try this on either machine, or both. Do this:

echo %@regdelkey[HKCU\Software\Classes\.btm]

Then run TCCBATCH.BTM, if you haven't already, and see whether your shortcuts start working as expected.

Thanks to David Marcus for the explanation of "Mark" (mind-boggling as it is). I decided to give the "QuickEdit Mode" a try, and that seems a lot easier. I do realize that I need to RTFM about this QuickEdit Mode, but I must say that my initial impression is that TCC seems to totally waste the right mouse button. I was surprised to NOT see a popup context menu with a zillion options, one of which was "copy". Oh well, I'm starting to think it's not a perfect world.

If you're running TCC standalone, the right-click context menu is provided by the Windows console handler; AFAIK there's nothing Rex can do to customize it. On the other hand, he can and does provide some interesting new items in the equivalent menu in Take Command.

 

[David Marcus]

On the other hand, he can and does provide some interesting new items in the equivalent menu in Take Command.

Copy and paste is much better in a Take Command tab. I have "Linux-style selection" checked, so just click, drag, release, and you are done.

 

[David Marcus]

Thanks to David Marcus for the explanation of "Mark" (mind-boggling as it is).

Note I said that was Windows for you. So, you can thank Microsoft. If you run TCC standalone, then Windows is handling the window. And so QuickEdit mode is also from Microsoft.

 

[NickCupery]

Here is the result of Charles' suggestion, on my Win XP Pro SP3 system:

-------------------------------------------------------------------
F:\NICK>echo %@regdelkey[HKCU\Software\Classes\.btm]
0

F:\NICK>
-------------------------------------------------------------------

When I do this on my Win 7 Pro x64 system, I get the result "1"
(without the quotes) instead of 0.

I ran TCCBatch.btm (again) after this, and shortcuts still don't work on my
Win XP machine. HOWEVER, after I ran TCCBatch.btm on my Win 7 machine,
my shortcuts there WORK JUST FINE! Man, I'm thinking I'm on the home
stretch now! Interesting to me, I was surprised about all the grief I encountered
on the Win 7 machine, about running TCCBatch.btm in Administrator Mode.
I finally did all that, and now things work. This is surely the first time I've run
TCCBatch.btm on the Win 7 machine, because I would surely have remembered
all the grief.

So, now I am wondering if maybe my TCCBatch.btm (which I have run several
times) somehow didn't "take" on my Win XP machine, due to this Administrator
Mode gotcha (which TCCBatch.btm never mentions on the Win XP machine).
Obviously, I need to run a few experiments after logging in as Administrator.
This may take a while, given that I do have work to do today, but I will report
any meaningful results.

Thanks to both Charles and David for pointing out the large difference between
a standalone TCC window and a TCC (looking) window within a TCMD session. That distinction had gone right over my head. Now that you've mentioned it,
QuickEdit Mode seems easily demented enough to have come from Microsoft. :-)

-- Nick

 

[NickCupery]

Okay, I tried a few more things, the results of which ranged from disastrous
to unsuccessful. (It's amazing how disastrous can make unsuccessful
suddenly look pretty good.) Here's the chronology:

I first removed "CMDHere Powertoy for Windows XP", and then I removed TCMD.

Then I rebooted the machine.

Then I looked in the folder where TCMD had been previously installed, and,
sure enough, all the files were gone, except for my own handmade TCSTART.BTM
which I was glad to see still there.

Then I noticed that my TCC shortcut still existed in the Quick Launch bar (which
I consider fair enough), and that "TCC prompt here" still existed in my right-click
menus (which I do NOT consider fair enough, but I admit I have no idea how
to remove such items myself -- maybe Msoft makes it impossible).

Then, just for the halibut, I double clicked on the TCC shortcut in the Quick Launch
bar. I got the expected Microsoft flashlight search thingie. Same result when I
tried to invoke "TCC prompt here", again as expected.

Then, I reinstalled TCMD, placing it in the exact same folder as before (and
telling it to "remove older versions").

Then I double-clicked on the TCC shortcut in the Quick Launch bar, and TCC
CRASHED ("would you like to send a report to Microsoft?"). Same CRASH
when I tried "TCC prompt here" on a folder.

Then I deleted the TCC shortcut from my Quick Launch bar, and dragged another
brand new shortcut to TCC out onto my desktop. I double-clicked it, and got
the same CRASH. This was unexpected!

Not feeling too good at this point, but I knew what to do: Reboot.

When I rebooted again, TCC no longer crashed, either from shortcuts or from
"TCC prompt here". Whew.

Then I ran TCCBatch.btm, telling it yes to .BAT and .BTM but no to .CMD.
And I ran TCCHere.btm again, even though that feature was working anyway
(due to an incomplete removal process).

However, it STILL DOES NOT WORK. I still cannot pass a command-line
argument to a .BTM file from a shortcut. <grrrr>

I'm still open for ideas, but this is getting really old. I need to get back to
my life at some point. :-)

-- Nick

 

[David Marcus]

What happens when you run Steve's btm file?

 

[Charles Dye]

I ran TCCBatch.btm (again) after this, and shortcuts still don't work on my Win XP machine. HOWEVER, after I ran TCCBatch.btm on my Win 7 machine, my shortcuts there WORK JUST FINE! Man, I'm thinking I'm on the home stretch now!

Well, I think I understand what was going on on the Win7 machine (bad file association, created by Explorer, easy to do), but at present I'm mystified about the XP box! I'll keep thinking about it.

 

[vefatica]

On Wed, 25 May 2011 10:07:53 -0400, NickCupery <> wrote:

|However, it STILL DOES NOT WORK. I still cannot pass a command-line
|argument to a .BTM file from a shortcut. <grrrr>

Can you pass, with a shortcut, an argument to a BAT file? ... to a CMD file?

You might try a shortcut to something both TCC and CMD can run, say

ver > output_file
echo arg1 is %1 >> file,/CODE]

Make three such files, maybe test.btm, test.bat, and test.cmd.

Then run each from the same shortcut, editing the shortcut's properties each
time to make it point to the right script (btm, bat, cmd) and examining
output_file after each attempt.

That should determine if it's BTM, or TCC, or the whole shortcut mechanism
that's broken.

 

[NickCupery]

>Can you pass, with a shortcut, an argument to a BAT file? ... to a CMD file?
>
>You might try a shortcut to something both TCC and CMD can run, say
>
>

ver > output_file
>echo arg1 is %1 >> file,/CODE]
>
>Make three such files, maybe test.btm, test.bat, and test.cmd.
>
>Then run each from the same shortcut, editing the shortcut's properties each
>time to make it point to the right script (btm, bat, cmd) and examining
>output_file after each attempt.
>
>That should determine if it's BTM, or TCC, or the whole shortcut mechanism
>that's broken.

Hey Vince, that's good thinking!  Dunno why I haven't tried that already.
No excuse.  Will do ASAP.  Um, I must admit I don't understand what you
meant by the use of CODE (or /CODE), and I don't know what you meant by
the square-brackets (or why there are three of them).

 -- Nick

 

[vefatica]

On Wed, 25 May 2011 15:23:04 -0400, NickCupery <> wrote:

|Hey Vince, that's good thinking! Dunno why I haven't tried that already.
|No excuse. Will do ASAP. Um, I must admit I don't understand what you
|meant by the use of CODE (or /CODE), and I don't know what you meant by
|the square-brackets (or why there are three of them).

Those are "tags". When viewed on the web forum, stuff tagged as CODE appear
differently, in a box, monospaced ... looks better.

 

[David Marcus]

>Um, I must admit I don't understand what you
meant by the use of CODE (or /CODE), and I don't know what you meant by
the square-brackets (or why there are three of them).

Just ignore all that. Those are tags for formatting your forum post, but Vince typed a comma instead of a left bracket, so the forum just displayed the codes.

 

[NickCupery]

Hmmm, that

 and

business does have
sort of an HTML look to it, now that I look again. :-)
I guess the reason I didn't guess something like that is
because whenever I am concentrating on this batch file
stuff I am expecting mind-numbing syntax anyway.

Okay, I tried Vince's idea but no go. I cannot get CMD.EXE
associated with .CMD files. They are still associated with TCC,
so I guess the TCC removal process failed to disassociate that
file type so it is left over from before.

I went to Folder Options in the Control Panel, and looked at
all my file associations. Oddly, CMD is not in the list AT ALL
(even though I know it is associated with TCC). I suppose this
is yet another case of Microsoft protecting me from myself.
So I told it to define a "new" file-type of CMD. Then I looked
in the list it suggested, and CMD was not there (although TCC
was). So I told it to "browse" to C:\WINDOWS\System32\
and then I selected CMD.EXE. The "always use this..." checkbox
was checked, but it was grayed-out, so I had done all I could do.
When I then explicitly typed "TestTCC.CMD", TCC ran the batch
file instead of CMD.EXE.

I am about to give up. Maybe a few beers will improve my mood
enough to give this another go tomorrow morning.

-- Nick

 

[David Marcus]

I cannot get CMD.EXE
associated with .CMD files. They are still associated with TCC,
so I guess the TCC removal process failed to disassociate that
file type so it is left over from before.

Since you created the association by running the tccbatch.btm file, I don't understand why you would expect the uninstaller to undo it.

I would have suggested that you not associate bat and cmd files with TCC, but I suppose it is too late for that.

Here are the normal Windows values:

C:\>assoc .cmd
.cmd=cmdfile

C:\>ftype cmdfile
cmdfile="%1" %*

C:\>assoc .bat
.bat=batfile

C:\>ftype batfile
batfile="%1" %*

 

[NickCupery]

>Since you created the association by running the tccbatch.btm file, I don't understand why you would expect the uninstaller to undo it.

I don't understand why you don't understand. :-) Since making the file-type association is part of the installation process, UNmaking the association should be part of the UNinstall process. Sorta like taking yer empty beer cans with you when you leave the campsite. What is the point of leaving a file-type associated with something that doesn't even EXIST? No, I would not expect TCC to REasociate a file-type with its previous owner. I'm just saying that leaving it not associated at all is far preferable to leaving it associated with something that no longer exists. Just my opinion.


>I would have suggested that you not associate bat and cmd files with TCC, but I suppose it is too late for that.

Heh, I would suggest that myself, now that I know what I know.

I'm now thinking its time to go see what I have in the way of Restore Points
and/or backups. I've found that once a system gets truly HOSED, its best
to simply retreat.

-- Nick

 

[Charles Dye]

Okay, I tried Vince's idea but no go. I cannot get CMD.EXE associated with .CMD files. They are still associated with TCC, so I guess the TCC removal process failed to disassociate that file type so it is left over from before.

Here's something you can try. It might not work, but it probably won't make matters much worse. Unless it does; no warranties. Possibly you might have to run it as Administrator. Or as a regular user; or both.

@echo off

rem  WHACKASSOC.BTM -- Attempt to pound batch file associations back into shape

setlocal

do ext in /l bat cmd btm

   echo Whacking associations for .%@upper[%ext]:
   
   set rv=%@regdelkey[HKCU\Software\Classes\.%ext]

   assoc .%ext=%ext%file
   
   iff %ext == btm then
      ftype %ext%file="%_cmdspec" /c "%%1" %%*
   else
      ftype %ext%file="%%1" %%*
   endiff
   
enddo

endlocal

 

[vefatica]

On Wed, 25 May 2011 21:34:39 -0400, NickCupery <> wrote:

|>I would have suggested that you not associate bat and cmd files with TCC, but I suppose it is too late for that.
|
|Heh, I would suggest that myself, now that I know what I know.

It should be easy to correct that. The file types "batfile" and "cmdfile"
should still exist (TCC doesn't use them or remove them). It should be
sufficient to just re-associate .bat and .cmd with them, like this:

ASSOC .bat=batfile
ASSOC .cmd=cmdfile

That (above) alone should return to the default for .bat and .cmd. Check it
like this (these are, I believe, the default settings).

v:\> assoc .bat
.bat=batfile

v:\> assoc .cmd
.cmd=cmdfile

v:\> ftype batfile
batfile="%1" %*

v:\> ftype cmdfile
cmdfile="%1" %*

 

[Steve Fabian]

From: NickCupery
|| Since you created the association by running the tccbatch.btm file,
|| I don't understand why you would expect the uninstaller to undo it.
|
| I don't understand why you don't understand. :-) Since making the
| file-type association is part of the installation process, UNmaking
| the association should be part of the UNinstall process. Sorta like
| taking yer empty beer cans with you when you leave the campsite. What
| is the point of leaving a file-type associated with something that
| doesn't even EXIST? No, I would not expect TCC to REasociate a
| file-type with its previous owner. I'm just saying that leaving it
| not associated at all is far preferable to leaving it associated with
| something that no longer exists. Just my opinion.

Sorry, executing TCCBATCH.BTM (or any of the TC*HERE.BTM files) is NOT part of the installation process. They are executed by the just-installed TCC.EXE. That's why the UNINSTALLER cannot remove their effects. Maybe a version of the batch file in C. Dye's response to this post should be included with the TCMD distribution (and also UNDO versions of the TC*HERE.BTM files).
--
Steve

 

[Charles Dye]

Maybe a version of the batch file in C. Dye's response to this post should be included with the TCMD distribution (and also UNDO versions of the TC*HERE.BTM files).

I actually have a fairly comprehensive (and totally undocumented) /UNDO option in RegTweaks.btm, but it won't do anything about per-user stuff; I never thought of it until this thread.