ON?
- Thread starter vefatica
- Start date
I don't fully understand. You get CTRL_C_EVENT and CTRL_BREAK_EVENT but can't get CTRL_CLOSE_EVENT!
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?
Now this is interesting. If I put
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
doesn't work at all. (???)
Am I missing something about taskend, or about using variables in "ON CLOSE"?
Note that
works just fine.
Well, it's not the variables. I can get all this to heppen when I X the console.
What is it with TASKEND?
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.
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
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.
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.
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.
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.
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.