Hidden console doesn't close

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
#1
With the latest build, I still get "Windows cannot end [console caption]" when I "X" (or File\Exit) TCMD. It does not happen with other versions of TCC as COMSPEC, and it doesn't happen if I check "Update Titles" in the TC12 options dialog.

New insight: My TITLEPROMPT (a user variable) is $s[%_pid]$s$s$p. The problem goes away if I "UNSET TITLEPROMPT" before X-ing TCMD.
 

rconn

Administrator
Staff member
May 14, 2008
10,100
85
#2
With the latest build, I still get "Windows cannot end [console caption]" when I "X" (or File\Exit) TCMD. It does not happen with other versions of TCC as COMSPEC, and it doesn't happen if I check "Update Titles" in the TC12 options dialog.

New insight: My TITLEPROMPT (a user variable) is $s[%_pid]$s$s$p. The problem goes away if I "UNSET TITLEPROMPT" before X-ing TCMD.
Still not reproducible here.
 
#3
On Sat, 23 Apr 2011 18:05:52 -0400, rconn <> wrote:

|---Quote (Originally by vefatica)---
|With the latest build, I still get "Windows cannot end [console caption]" when I "X" (or File\Exit) TCMD. It does not happen with other versions of TCC as COMSPEC, and it doesn't happen if I check "Update Titles" in the TC12 options dialog.
|
|New insight: My TITLEPROMPT (a user variable) is $s[%_pid]$s$s$p. The problem goes away if I "UNSET TITLEPROMPT" before X-ing TCMD.
|---End Quote---
|
|Still not reproducible here.

Did you double the "%" to make sure it's really variable.

It's now a pretty precise set of conditions under which the error happens. I
can reproduce it at will with other internal variables; for example, with "set
titleprompt=%%_ip" before X-ing TCMD. It even happens with titleprompt=foo.
 

rconn

Administrator
Staff member
May 14, 2008
10,100
85
#4
Did you double the "%" to make sure it's really variable.
Yes.

It's now a pretty precise set of conditions under which the error happens. I can reproduce it at will with other internal variables; for example, with "set titleprompt=%%_ip" before X-ing TCMD. It even happens with titleprompt=foo.
I cannot reproduce it under any set of conditions.

Anybody else able to reproduce this?
 
#7
On Sun, 24 Apr 2011 01:18:44 -0400, David Marcus <> wrote:

|---Quote (Originally by rconn)---
|Anybody else able to reproduce this?
|---End Quote---
|What are we supposed to do? Uncheck Update Titles, set titleprompt=%%_ip, close TC with the X? If so, I can't reproduce it.

It happens when "UpdateTitles" is checked.
 
#8
Anybody else able to reproduce this?
I'm not sure how useful a bunch of negative responses are, but I've unset Update Titles and tried various TITLEPROMPT values (with or without the doubled %% to delay expansion) and none of them result in any behaviour other than the expected immediate closure from the "X" or File>Exit.

It happens when "UpdateTitles" is checked.
Serve me right for not refreshing before replying, but I've now tried various combinations with and without Update Titles and none of them change the previous statement.
 
#10
On Sun, 24 Apr 2011 14:15:56 -0400, rconn <> wrote:

|---Quote (Originally by vefatica)---
|It happens when "UpdateTitles" is checked.
|---End Quote---
|
|Your original post said it happens when "UpdateTitles" is unchecked -- which is it?
|
|I can't make it happen either way.

Sorry about that. It happens when "UpdateTitles" is unchecked.

Rex, do you have any suggestions on how to figure out what's going on?
 

rconn

Administrator
Staff member
May 14, 2008
10,100
85
#11
Rex, do you have any suggestions on how to figure out what's going on?
If nobody else is able to reproduce this, there's very little chance I can do anything about it. It's almost certainly due to something else on your system (plugins, antivirus, screen managers, etc.), and unless you sent me your system I don't know how I can debug it.

Do you have a TCEXIT and if so, have you tried disabling it?

Did you try this without plugins?

Did you try this after disabling all the apps that might be injecting dll's into TCMD (antivirus, screen managers)?
 
#12
On Sun, 24 Apr 2011 16:35:19 -0400, rconn <> wrote:

|---Quote (Originally by vefatica)---
|Rex, do you have any suggestions on how to figure out what's going on?
|---End Quote---
|
|If nobody else is able to reproduce this, there's very little chance I can do anything about it. It's almost certainly due to something else on your system (plugins, antivirus, screen managers, etc.), and unless you sent me your system I don't know how I can debug it.
|
|Do you have a TCEXIT and if so, have you tried disabling it?
|
|Did you try this without plugins?
|
|Did you try this after disabling all the apps that might be injecting dll's into TCMD (antivirus, screen managers)?

No such software installed here. It happens with no plugins.

More insight: If I delete TCEXIT.BTM or put /IX in TCMD's COMSPEC the probem
goes away. Normally my TCEXIT.BTM exists but is empty. But the problem happens
with or without anything in TCEXIT.BTM. So now it seems you must have (and
execute) a TCEXIT.BTM (empty or not), have "UpdateTitles=No", and have
TITLEPROMPT set. Perhaps I'll find more conditions.
 
#14
I still can't reproduce it.

If you want people to reproduce it, start with a clean install, then say exactly what we need to do (e.g., create TCExit.btm).

Have you tried reproducing it on another computer? If you can't reproduce it, it isn't too likely we'll be able to.
No, in fact, I can't reproduce it on another machine. I tried on the machine at work which has updated cleanly since day one. Everything is the same there ... directory structure, INI file, start file. Because of the similarity between the directory structures, I copied the work install directory to home, and vice versa and just ran them. It still failed at home and didn't fail at work.

The computer at home is a multi-processor machine; the one at work is not. It could be a timing/communication problem because even if I cancel the "end program" dialog, the hidden TCC (and TCMD) terminate. Why it doesn't terminate in those first five seconds remains a mystery.
 
#16
On Sun, 24 Apr 2011 23:42:39 -0400, David Marcus <> wrote:

|---Quote (Originally by vefatica)---
|No, in fact, I can't reproduce it on another machine.
|---End Quote---
|Sounds like it is time to reinstall Windows.

I'll consider that when I have a problem with any other piece of software.
 
#17
I don't seem to be able to generate a failure, either.

On Sun, Apr 24, 2011 at 20:42, David Marcus <> wrote:


> ---Quote (Originally by vefatica)---
> No, in fact, I can't reproduce it on another machine.
> ---End Quote---
> Sounds like it is time to reinstall Windows.
>
>
>
>
>


--
Jim Cook
2011 Tuesday: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Wednesday.
 
#20
I also get "Windows cannot end [TCC]" if I have more than one tab, and I right-click on a TCC12 tab and choose "Close".

Rex, how does TCMD tell TCC to exit in this case?
Rex, if you would give me a well-chosen sequence of functions called by TCC after TCMD tells it to terminate, I could, with debugger breakpoints, get an idea where TCC gets stuck for 5 seconds (causing the "Windows cannot end" dialog).
 
#21
Jim Cook gave me this idea.

In the default (and only) tab, run a batch file containing only "DELAY 60". While it's running, try to "X" TCMD. I get "Windows cannot end [TCC]"

No problem X-ing TCC in that situation.
 
#23
Jim Cook gave me this idea.

In the default (and only) tab, run a batch file containing only "DELAY 60". While it's running, try to "X" TCMD. I get "Windows cannot end [TCC]"

No problem X-ing TCC in that situation.
Hee hee! And if I UNSET TITLEPROMPT before the above experiment the hidden console closes OK.
 
#25
Well, I still have the problem of "Windows cannot end [TCC]" when I have a TCEXIT file and all the ways I can alleviate it (short of deleting TCEXIT) somehow involve the console window's caption (unsetting TITLEPROMPT, using TITLE in TCEXIT.

It's pretty clear that after WM_SYSCOMMAND\SC_CLOSE TCC's behavior is different depending on whether it's in TCMD or not

Does TCMD or TCC do **anything** related to the console's caption after WM_SYSCOMMAND\SC_CLOSE is sent?

Can you think of any ways in which I might figure out what's going on?
 

rconn

Administrator
Staff member
May 14, 2008
10,100
85
#26
Well, I still have the problem of "Windows cannot end [TCC]" when I have a TCEXIT file and all the ways I can alleviate it (short of deleting TCEXIT) somehow involve the console window's caption (unsetting TITLEPROMPT, using TITLE in TCEXIT.

It's pretty clear that after WM_SYSCOMMAND\SC_CLOSE TCC's behavior is different depending on whether it's in TCMD or not

Does TCMD or TCC do **anything** related to the console's caption after WM_SYSCOMMAND\SC_CLOSE is sent?
No.
 
#27
On Mon, 16 May 2011 21:52:59 -0400, rconn <> wrote:

|---Quote (Originally by vefatica)---
|Well, I still have the problem of "Windows cannot end [TCC]" when I have a TCEXIT file and all the ways I can alleviate it (short of deleting TCEXIT) somehow involve the console window's caption (unsetting TITLEPROMPT, using TITLE in TCEXIT.
|
|It's pretty clear that after WM_SYSCOMMAND\SC_CLOSE TCC's behavior is different depending on whether it's in TCMD or not
|
|Does TCMD or TCC do **anything** related to the console's caption after WM_SYSCOMMAND\SC_CLOSE is sent?
|---End Quote---
|
|No.

No ideas at all!

In a test I found that there is no such problem if a third EXE sends
WM_SYSCOMMAND\SC_CLOSE to the TCC console window while it's hidden and in TCMD.
So I figure TCMD must have some additional interaction with the console window.
 
#29
On Mon, 16 May 2011 22:45:19 -0400, rconn <> wrote:

|---Quote---
|> So I figure TCMD must have some additional interaction with
|> the console window.
|---End Quote---
|No. (Even if it did, why are you the only one with the problem?)

I can't explain it but I believe that if enough folks tried to reproduce it,
someone would succeed. The problem seems a bit too specifically linked to
TCC12, TCMD12, TCEXIT, TITLEPROMPT, and TITLE to be blamed on outside
influences.