WINDOW (and more closing TCC woes)

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
#1
Why doesn't this work?

Code:
v:\> window topmost
Usage : WINDOW [MIN | MAX | RESTORE | HIDE | TOPMOST | NOTOPMOST | TOP | BOTTOM | TRAY | /POS=left,top,width,height | /SIZE=rows,columns | /TRANS=n | "title"]
And ... put "WINDOW RESTORE" in TCEXIT, try to kill a TCC with the "X" button ... it doesn't close for 5 seconds!
 

rconn

Administrator
Staff member
May 14, 2008
10,100
85
#2
Why doesn't this work?

Code:
v:\> window topmost
Usage : WINDOW [MIN | MAX | RESTORE | HIDE | TOPMOST | NOTOPMOST | TOP | BOTTOM | TRAY | /POS=left,top,width,height | /SIZE=rows,columns | /TRANS=n | "title"]
Because it's only valid in a tab window. (See the help.)

And ... put "WINDOW RESTORE" in TCEXIT, try to kill a TCC with the "X" button ... it doesn't close for 5 seconds!
[/QUOTE]

Not reproducible here.
 
#3
On Thu, 28 Apr 2011 22:40:12 -0400, rconn <> wrote:

|---Quote---
|And ... put "WINDOW RESTORE" in TCEXIT, try to kill a TCC with the "X" button ... it doesn't close for 5 seconds!
|---End Quote---
|[/QUOTE]
|
|Not reproducible here.

Utterly reproducible here. And it also happens on a second machine (where my
problem with TCMD and "Windows cannot end [console_title]" doesn't happen).

Anyone else?
 
#4
Yes. If I add a '*WINDOW RESTORE' to my TCEXIT then

a) if I close a stand-alone TCC session using the RH corner "X" I see a roughly five second delay. The same effect occurs if I right-click on the Taskbar icon and select Close Window or use the Close option on the drop down menu from the window's title bar but not if I use the EXIT command.

b) if I close a TCC Prompt tab in TCMD using the "X" on the tab title I see a similar delay. The same effect is seen if right-clicking on the tab title and selecting Close. However, somewhat confusingly, in this situation TCEXIT does not seem to be run. An EXIT command behaves normally (no delay) and does run TCEXIT.

c) if I close TCMD using the RH corner "X" then there is no delay but none of the open TCC tabs seem to run TCEXIT

The non-invocation of TCEXIT in the above scenarios is something of an issue for me as I have my own history list processing being handled via that route.

FWIW I have an explicit TCSTART / TCEXIT path defined in my TCC options and the only copies of either TCSTART or TCEXIT on my system are in that directory.

TCC 12.10.63 x64 Windows 7 [Version 6.1.7601]
 
#5
My preceding post is a little misleading, because it seems that TCEXIT does get run by the various closure methods but that it isn't always allowed time to finish. Specifically I had added the following ECHO statement to the beginning of both TCSTART and TCEXIT:
Code:
ECHO %@NAME[%_BATCHNAME] {%_PID}: invoked %_ISODATE at %_TIME {%_TRANSIENT %_PIPE %_TCTAB %_TCTABACTIVE %_TCTABS %_SHELL} >>%@PATH[%_BATCHNAME]TCMD_AUTO.LOG
and it was the non-existence of output from this statement that I was using to identify whether or not TCEXIT was getting invoked. If I replace that line with the much simpler:

Code:
ECHO %@NAME[%_BATCHNAME]: invoked %_ISODATE at %_TIME >>%@PATH[%_BATCHNAME]TCMD_AUTO.LOG
then I do get log entries and, without the WINDOW RESTORE command, I also get my history logging output. With the WINDOW RESTORE however (which immediately follows the ECHO before any other processing is performed) the rest of the logic never seems to get executed.

Rex, is there any particular reason why the handling of a close has to be any different than when the user enters an EXIT command??
 
#6
---- Original Message ----
From: Steve Pitts
| Quote:
| Originally Posted by vefatica
|| Anyone else?
|
| Yes. If I add a '*WINDOW RESTORE' to my TCEXIT then
...
|
| b) if I close a TCC Prompt tab in TCMD using the "X" on the tab title
| I see a similar delay. The same effect is seen if right-clicking on
| the tab title and selecting Close. However, somewhat confusingly, in
| this situation TCEXIT does not seem to be run. An EXIT command
| behaves normally (no delay) and does run TCEXIT.

I do not understand - the presence of the '*WINDOW RESTORE' command in TCEXIT causes a delay, but TCEXIT is not executed? Isn't this selfcontradictory? Or do you mean that the commands in TCEXIT following the '*WINDOW RESTORE' command are ignored? Please test more and elaborate!
--
Steve
 

rconn

Administrator
Staff member
May 14, 2008
10,100
85
#7
Utterly reproducible here. And it also happens on a second machine (where my problem with TCMD and "Windows cannot end [console_title]" doesn't happen).
Tried it on 5 machines here and can't reproduce on any of them.

I'm not too worried about it, because:

1) I cannot conceive of any reason to be doing that in TCEXIT.

2) All WINDOW RESTORE does is call the SetWindowPlacement API, so if it's hanging it'd have to be there -- so I couldn't fix it anyway.
 
#8
On Fri, 29 Apr 2011 10:10:18 -0400, rconn <> wrote:

|2) All WINDOW RESTORE does is call the SetWindowPlacement API, so if it's hanging it'd have to be there -- so I couldn't fix it anyway.

I can confirm that it's SetWindowPlacement() not returning. I replaced "WINDOW
RESTORE" in TCEXIT with a call to a plugin which did this:

Code:
POINT pt = {0,0};
RECT rc;
GetWindowRect(global.hWndConsole, &rc);
Beep(440,500);
WINDOWPLACEMENT wp = {sizeof(WINDOWPLACEMENT), 0, SW_RESTORE, pt, pt, rc};
Printf(L"%d\r\n", SetWindowPlacement(global.hWndConsole, &wp));
I heard the beep right away (so GetWindowRect() is OK). But
SetWindowPlacement() returned 1 (success) only after a 5 second delay. I
suspect it's the same 5 second delay that exists before the "Windows cannot end
..." dialog because, in these tests, I sometimes see that dialog flash for just
a moment. Perhaps you just can't do that to a console window after SC_CLOSE has
been generated.

It would now seem likely that this or something similar is causing the "Windows
cannot end [console]" dialog when I "X" TCMD. Does either TCMD or TCC call
SetWindowPlacement() on the console window when I "X" TCMD? Does TCMD send
WM_SYSCOMMAND/SC_CLOSE when it wants to kill it's TCC clients?
 

rconn

Administrator
Staff member
May 14, 2008
10,100
85
#9
It would now seem likely that this or something similar is causing the "Windows cannot end [console]" dialog when I "X" TCMD. Does either TCMD or TCC call SetWindowPlacement() on the console window when I "X" TCMD?
No.

Does TCMD send WM_SYSCOMMAND/SC_CLOSE when it wants to kill it's TCC clients?
Yes.
 
#10
On Fri, 29 Apr 2011 11:12:24 -0400, rconn <> wrote:

|---Quote (Originally by vefatica)---
|It would now seem likely that this or something similar is causing the "Windows cannot end [console]" dialog when I "X" TCMD. Does either TCMD or TCC call SetWindowPlacement() on the console window when I "X" TCMD?
|---End Quote---
|
|No.
|
|
|---Quote---
| Does TCMD send WM_SYSCOMMAND/SC_CLOSE when it wants to kill it's TCC clients?
|---End Quote---
|
|Yes.

Then I continue to suspect that this has something to do with my "Windows cannot
end [console]" dialog when I "X" TCMD. I was under the impression that TCMD
constantly kept the console window hidden ... somehow.

Anyway, I'll keep investigating.

Perhaps remotely related, FWIW, and FYI, I recently discovered another anomaly
regarding consoles, namely that SetConsoleWindowInfo() is **not** synchronous.
It returns before the underlying SetWindowPos() returns (confirmed by MicroSoft,
in Win7 too). This is easily verified by SetConsoleWindowInfo() followed
immediately by GetWindowRect(); GetWindowRect() will return stale info for a
while. That had always been a problem in my CONSIZE plugin where resizing
horizontally and vertically might have to be done separately. MS sent me a
~100-line workaround (do all the font/border/titlebar(et c.) size computations
and use SetWindowPos() instead); I sent them a 10-line workaround (wait for a
WinEventHook to capture EVENT_OBJECT_LOCATIONCHANGE). :-)
 
#11
Isn't this selfcontradictory?
Indeed, hence the follow up post (which from a comment elsewhere I guess must have 'crossed in the post' with your original response).

Steve Fabian said:
Please test more and elaborate!
I'm still not sure that I understand what I'm seeing when I close Take Command using its File menu or window furniture. As documented above I have been trying to track the start up and shutdown processing with the following ECHO command at the start of both TCSTART and TCEXIT (only preceded by an @ECHO OFF):
Code:
ECHO %@NAME[%_BATCHNAME] {%_PID}: invoked %_ISODATE at %_TIME {%_TRANSIENT %_PIPE %_TCTAB %_TCTABACTIVE %_TCTABS %_SHELL} >>%@PATH[%_BATCHNAME]TCMD_AUTO.LOG
but I'm not seeing an exit entry for each start entry where Take Command is terminated rather than each TCC being EXITed, even now that I've removed the WINDOW RESTORE.

Here are the entries following a start of Take Command (before leaving the computer for some time to eat some lunch and watch some snooker), the creation of a second TCC tab and then termination by clicking the X control of Take Command:

Code:
TCSTART {5564}: invoked 2011-04-29 at 13:02:04 {0 0 1 1 2 0}
TCSTART {3672}: invoked 2011-04-29 at 16:26:28 {0 0 1 1 2 0}
TCEXIT {3672}: invoked 2011-04-29 at 16:26:36 {0 0 0 0 0 0}
From the variable values I would assume that the TCC was disconnected from Take Command before TCEXIT ran, and perhaps the other TCC session didn't write to the log because it was already being written to. However, I then opened a new Take Command, initiated a second TCC within it, switched back and closed the first TCC before closing Take Command via the X control and I got:

Code:
TCSTART {5448}: invoked 2011-04-29 at 16:27:48 {0 0 1 1 1 0}
TCSTART {3388}: invoked 2011-04-29 at 16:28:23 {0 0 1 1 2 0}
TCEXIT {5448}: invoked 2011-04-29 at 16:28:27 {0 0 1 1 2 0}
with no indication that the second TCC even ran TCEXIT.

I am confused :( Does TCC wait for TCEXIT to finish or not??
 
#12
On Fri, 29 Apr 2011 10:55:07 -0400, vefatica <> wrote:

|I can confirm that it's SetWindowPlacement() not returning. I replaced "WINDOW
|RESTORE" in TCEXIT with a call to a plugin which did this:

I can also cause the delay with a plugin, called by TCEXIT, that calls
SetWindowText() on the console window. And I wouldn't be surprised if other
window functions caused it too. Does TCMD do any such things after sending
WM_SYSCOMMAND/SC_CLOSE?
 

rconn

Administrator
Staff member
May 14, 2008
10,100
85
#14
I am confused :( Does TCC wait for TCEXIT to finish or not??
TCC waits.

Windows doesn't. If you close via the X, Windows tells the process to close and gives it 4-5 seconds to finish up. If it doesn't, Windows kills it.

So if you have a potentially long TCEXIT, it's a really, really bad idea to close your TCC window with the X.
 
#15
On Fri, 29 Apr 2011 12:31:55 -0400, rconn <> wrote:

|---Quote (Originally by vefatica)---
|
|I can also cause the delay with a plugin, called by TCEXIT, that calls
|SetWindowText() on the console window. And I wouldn't be surprised if other window functions caused it too. Does TCMD do any such things after sending WM_SYSCOMMAND/SC_CLOSE?
|---End Quote---
|
|No.

I can also cause the delay by having TCEXIT call a (one-line) plugin which uses
SendMessage(hWndConsole, ...).

The docs warn that things may not work correctly after CTRL_CLOSE_EVENT.

In any event, I have the problem that when I "X" TCMD, after 5 seconds, "Windows
cannot end [console]". It would appear that after receiving
WM_SYSCOMMAND/SC_CLOSE, TCC is doing something which blocks. I have found
several such things and no doubt there are more. Have you any suggestions for
further debugging?
 
#16
Tif you have a potentially long TCEXIT, it's a really, really bad idea to close your TCC window with the X
I hear you. I have to admit that in general use I would always use the EXIT command, so this isn't a big deal for me. It was just that in trying to recreate Vince's issue(s) I was messing around in unusual ways and was confused by what I was seeing. Thanks for the explanation.