WAD Unwanted message boxes

[vefatica]

When I

g:\tc15\tcmd /d "%userprofile\templates"

(a junction) I see a TCMD with no tabs and must successively dismiss 3 message boxes (all the same, see below) ... then a tab appears with TCC in the requested directory. And apparently, the requested directory is also TCMD's current directory since, if I "Tabs\Run..." TCC without specifying a directory, that's where it starts.

[Window Title]
Location is not available
[Content]
C:\Users\vefatica\Templates is not accessible.
Access is denied.
[OK]

 

[vefatica]

Note that when I try that from an elevated TCC, I also get the message boxes. What's different is that, instead of TCMD and TCC eventually starting in the specified directory, they both start in the CWD of the parent TCC. So it's actually worse when elevated!

 

[vefatica]

Also,

When I remove the special, overriding "deny everyone list contents/read data" permission, the message boxes go away.

The /D not working when TCMD was started by an elevated TCC was MY FAULT. I have (paraphrasing) "if elevated cdd v:\" in TCSTART. That explains why the TCC inside TCMD always started in v:\. I must have been mistaken about TCMD not starting where specified. Today, trying with "/D "%userprofile\cookies" (still having the DENY permission), TCMD starts in the right place (after 3 message boxes).

OT: I've read that the purpose of those junctions is to make legacy apps, ones with hard-coded old-fashioned paths, work correctly. I understand the goal but I don't understand the "deny everyone read data" permission. How's such a legacy app (a browser maybe) supposed to work correctly if it can't **read** what's in %userprofile\Cookies?

 

[rconn]

When I

g:\tc15\tcmd /d "%userprofile\templates"

(a junction) I see a TCMD with no tabs and must successively dismiss 3 message boxes (all the same, see below) ... then a tab appears with TCC in the requested directory. And apparently, the requested directory is also TCMD's current directory since, if I "Tabs\Run..." TCC without specifying a directory, that's where it starts.

Not reproducible here. But those message boxes aren't coming from Take Command or TCC.

 

[vefatica]

According to SPY++ TCMD owns them. The client area (containing the message) is of class "Direct UIHWND", no caption, process: TCMD. The frame/parent window (with caption "Location is not available") is of class "#32770 (Dialog)", process: TCMD. And the parent of that one has caption "TC 15.01".

 

[vefatica]

I get the same message box (sometimes more than one) if I try to open %userprofile\cookies in TCMD's folders or list view. I suppose they're coming from the controls you use in those windows. And it's the same message box Explorer shows me if I try to enter %userprofile\cookies. I don't suppose there's anything you can do about it.

I'll ask again ... if the junctions in %userprofile exist for the sake of legacy apps with hard-coded old-fashioned paths why in the world would everyone be denied list/read access to their targets? Does anyone know what good those things are?

 

[vefatica]

I get the same message box (sometimes more than one) if I try to open %userprofile\cookies in TCMD's folders or list view. I suppose they're coming from the controls you use in those windows. And it's the same message box Explorer shows me if I try to enter %userprofile\cookies. I don't suppose there's anything you can do about it.

If that's what it is, a quick FindFirstFile on the /D-specified directory should warn you that it will happen.

 

[rconn]

View attachment 403
According to SPY++ TCMD owns them. The client area (containing the message) is of class "Direct UIHWND", no caption, process: TCMD. The frame/parent window (with caption "Location is not available") is of class "#32770 (Dialog)", process: TCMD. And the parent of that one has caption "TC 15.01".

That's coming from the Windows dll's; it isn't anywhere in TCMD / TCC. And no, there isn't anything I could do about it short of rewriting the Windows tree and list view controls.

I still can't reproduce that behavior -- presumably you have something in your TCMD.INI or TCSTART. (Maybe trying to set the folder or list view start directory?)

 

[vefatica]

Do you have all those junctions in your Win7 %userprofile with "deny everyone list/read"? If so, what happens if you try to navigate to one of them in TCMD's Explorer-like controls? It can't show the contents. As I see it, the control will produce those message boxes whenever it tries to list the contents of one of those things ... I suppose even at start-up if one was specified by "/D".

The message boxes happen even when TCMD's COMSPEC (only have the default tab) is set to CMD, so I rule out TCC.

As for **me** trying to control where the list view window starts, I have no idea what I'd even try and I wouldn't have thought it possible. If "/D" is specified, that's where TCMD starts and that's where the list view is initialized. Isn't that expected behavior?

 

[rconn]

As for **me** trying to control where the list view window starts, I have no idea what I'd even try and I wouldn't have thought it possible. If "/D" is specified, that's where TCMD starts and that's where the list view is initialized. Isn't that expected behavior?

/D doesn't have anything to do with where TCMD starts; it just sets the directory to be displayed in the folder / list view windows.

 

[vefatica]

TCMD's current directory DOES SEEM BE what's specified in a "/D" start-up option (and not change thereafter). I say that because whenever I start TCMD with a "/D" option and then Menu\Tabs\Run(in a new tab) ... CMD (or TCC) ... without specifying a directory, the tab (CMD/TCC) starts in the directory that was originally in the "/D" option (and that's regardless of what's showing it the list view) ... I figure it's TCMD's current directory.

In any event the message boxes could be avoided by a little check on the directory specified with "/D"; FindFirstFile will fail with "Access denied" (5) for junctions like the ones under discussion. It's not unreasonable for a user to try, for example, TCMD /D "%userprofile\my documents". It's of no value to him to dismiss 3 message boxes and then find that the contents are *NOT* displayed in the ListView.

Completely off-topic ... is it possible, say with a toolbar button, for a user to start a new tab with TCC having CWD equal to the directlry currently showing in (or selected in) the ListView?

 

[Charles Dye]

Completely off-topic ... is it possible, say with a toolbar button, for a user to start a new tab with TCC having CWD equal to the directlry currently showing in (or selected in) the ListView?

Certainly. See the %_TCFOLDER variable. (Doing the same for CMD.EXE would involve a bit of trickery.)

 

[vefatica]

Certainly. See the %_TCFOLDER variable. (Doing the same for CMD.EXE would involve a bit of trickery.)

That could work for any program if (1) %_tcfolder were a TCMD variable (or even pseudo-variable) and (2) buttons expanded it.

This works from a TCC tab command line to change it to a CMD tab.

start /b cmd & exit

But after that, when TCMD exits, the CMD becomes a zombie.

So it looks like a strategy of starting a TCC to (change to %_TCFOLDER and) start CMD won't work very well.

 

[Charles Dye]

That could work for any program if (1) %_tcfolder were a TCMD variable (or even pseudo-variable) and (2) buttons expanded it.

Why not just set up your button to run TCC.EXE /K CDD "%_TCFOLDER"

 

[vefatica]

Why not just set up your button to run TCC.EXE /K CDD "%_TCFOLDER"

My (recent) point was to start other things in %_tcfolder. If I follow your suggestion with (e.g.) "& (start /b cmd) & exit" the CMD starts in the right place, but when TCC exits, the new tab closes and the CMD is zombied.

 

[Charles Dye]

My (recent) point was to start other things in %_tcfolder. If I follow your suggestion with (e.g.) "& (start /b cmd) & exit" the CMD starts in the right place, but when TCC exits, the new tab closes and the CMD is zombied.

I don't see any need for START. Set your button up to e.g. TCC.EXE /C CDD "%_TCFOLDER" & CMD.EXE
(or whatever program you want in place of CMD.)

 

[vefatica]

I don't see any need for START. Set your button up to e.g. TCC.EXE /C CDD "%_TCFOLDER" & CMD.EXE
(or whatever program you want in place of CMD.)

With that, TCC will continue to run until CMD exits. I don't like that sort of thing.

 

[Charles Dye]

With that, TCC will continue to run until CMD exits. I don't like that sort of thing.

Well, then, how about START /D"%_TCFOLDER" /TAB /PGM CMD.EXE or the like?

 

[vefatica]

Well, then, how about START /D"%_TCFOLDER" /TAB /PGM CMD.EXE or the like?

Whoa! Apparently TCMD itself knows what %_TCFOLDER means (should be documented). So it's as simple as:

Program: CMD
Directory: %_tcfolder

I wonder if TCMD has other _internal variables that might be of use.

 

[vefatica]

A little experimentation shows that TCMD al least tries to expand any %_VARIABLE, often giving what you'd expect (from TCMD).
One that would be useful would be TCMD's internal "Comspec" ... the one specified in the TCMD Option dialog ... the one new tabs use by default. It would be useful as "Command:" on a button or in Tabs\Run (followed by some goal-specific command). My Option\Comspec is "g:\tc15\tcc /q". When TCMD expands "%COMSPEC" it gives the default (CMD); it gives an empty string for %_CMDSPEC and %_CMDPROC. Have I simply missed it? Is there a variable TCMD will expand to its internal "Comspec"?