ON?

[vefatica]

Does any version of the ON command catch closing the console (via the control menu or the "X")?

 

[rconn]

No. I tried to do that a while back, but it's not possible in Windows.

 

[vefatica]

No. I tried to do that a while back, but it's not possible in Windows.

I don't fully understand. You get CTRL_C_EVENT and CTRL_BREAK_EVENT but can't get CTRL_CLOSE_EVENT!

 

[rconn]

CTRL_CLOSE_EVENT sets the ON CLOSE flag. But that wasn't what you asked for -- closing the console window is not the same as closing TCC.

 

[vefatica]

CTRL_CLOSE_EVENT sets the ON CLOSE flag. But that wasn't what you asked for -- closing the console window is not the same as closing TCC.

I'm becoming more confused. With no regard to TCMD ... CTRL_CLOSE_EVENT is sent to a console CtrlHandler (like CTRL_C_EVENT and CTRL_BREAK_EVENT). Stand-alone TCC apparently catches it since it triggers the running of TCEXIT.BTM (probably among several other actions). Why, in a stand-alone TCC, can't it trigger some ON condition?

 

[rconn]

As I said, you can use ON CLOSE. But you probably won't be able to do anything with it, because your session is being killed. (You can't prevent the session from ending, and you can't delay it.)

 

[vefatica]

As I said, you can use ON CLOSE. But you probably won't be able to do anything with it, because your session is being killed. (You can't prevent the session from ending, and you can't delay it.)

Now this is interesting. If I put

on close (beep & delay 4 & beep & quit)

in my BTM and X the console while it's running, I get both beeps with 4 seconds in between. But what I really want to happen, (and reckon should take much less than 4 seconds), namely

on close (taskend /f %startpid1 & taskend /f %startpid2 & quit)

doesn't work at all. (???)

Am I missing something about taskend, or about using variables in "ON CLOSE"?

Note that

on break (taskend /f %startpid1 & taskend /f %startpid2 & quit)

works just fine.

 

[vefatica]

Well, it's not the variables. I can get all this to heppen when I X the console.

on close ( echo %startpid1 %startpid2 & beep & delay 4 & beep & quit)

What is it with TASKEND?

 

[rconn]

There are two things that happen when you X the console:

1) TCC will run any ON CLOSE argument
2) TCC will run TCEXIT and exit the app

Note that these will run *simultaneously*, so unless you somehow synchronize their operation you will not have a happy result.

 

[vefatica]

There are two things that happen when you X the console:

1) TCC will run any ON CLOSE argument
2) TCC will run TCEXIT and exit the app

Note that these will run *simultaneously*, so unless you somehow synchronize their operation you will not have a happy result.

I don't use a TCEXIT. What then? As I said before, I can "beep & delay 4 & beep" in ON CLOSE, but I can't "taskend %_startpid & quit". In that second case, taskend just seems to hang, doing nothing, until ~5 seconds have elapsed and TCC is terminated

 

[rconn]

Regardless of whether you have a TCEXIT, TCC is still exiting the app immediately after receiving the close notification (WM_ENDSESSION). TCC calls the internal exit function, which looks for TCEXIT before shutting everything down. Before looking for (and running) TCEXIT, TCC will shut down all the batch files. After running TCEXIT (or continuing on if it doesn't find one), TCC unloads various modules and exits.

In your taskend case, TCC has already unloaded a lot of dll's and is busy shutting down everything else. You have an ON CLOSE thread that's all alone, with no Windows dll's or TCC supporting threads.

 

[vefatica]

Well, it's no big deal. My immediate concern was terminating some STARTed processes and that's more easily handled with a job object (with /K working).

That said, it doesn't work any better in a TCMD tab. All in all, ON CLOSE seems rather undependable.

 

[rconn]

Well, it's no big deal. My immediate concern was terminating some STARTed processes and that's more easily handled with a job object (with /K working).

That said, it doesn't work any better in a TCMD tab. All in all, ON CLOSE seems rather undependable.

As with your 100 other posts on the same topic, you should file a complaint with Microsoft. It's conhost.exe that's in control of all of that, not TCC.

 

[vefatica]

As with your 100 other posts on the same topic, you should file a complaint with Microsoft. It's conhost.exe that's in control of all of that, not TCC.

It has been by belief that after CTRL_CLOSE_EVENT, Windows gives a console app 5 seconds (unmolested) to perform cleanup. If TCC is dismantling itself, and unloading modules before the ON CLOSE is run, I don't think Microsoft will be able to help me.

 

[rconn]

It has been by belief that after CTRL_CLOSE_EVENT, Windows gives a console app 5 seconds (unmolested) to perform cleanup. If TCC is dismantling itself, and unloading modules before the ON CLOSE is run, I don't think Microsoft will be able to help me.

Windows gives a console app *up to* 4 or 5 seconds (but not guaranteed). I have seen Windows forcibly shut down a console app in a lot less time than that.

TCC is not dismantling itself before ON CLOSE is run, it's dismantling itself at the same time that ON CLOSE is run. The option here is that TCC could run your ON CLOSE and run the (near certain) risk of trashing itself, or clean itself up appropriately and let your ON CLOSE take care of itself. It can't do both.