The popup is not special. This will cause the crash too.
v:\> type test1.btm
echo test2.btm returned %@exec[call v:\test2.btm]
v:\> type test2.btm
cdd d:\
cdd -
quit 17
v:\> test1.btm
test2.btm returned 17
v:\> cdd v:\
v:\> type test1.btm
echo test2.btm returned %@exec[call v:\test2.btm]
v:\> type test2.btm
cdd d:\
cdd -
quit 17
v:\> test1.btm
test2.btm returned 17
v:\>
That looks good, right? If I now attempt a change of directory via the popup directory history, TCC crashes. There's nothing in...
If the BAT file you're interrupting (most likely the most deeply nested one) is being CALLed in a loop by a BAT file higher up the nesting chain, that higher up BAT file will continue CALLing the one you've interrupted. That is, Ctrl-C and Ctrl-Break don't travel up a nested sequence of BAT files.
I'd wait until I could make a better case, like one that didn't depend on TCC, or other TCC users seeing the same thing. Have you tried Ctrl-C in CMD? DIR /S on the system drive would be a good one to try in CMD.
Your GLOBAL command worked fine here with both TCC31 and TCC32 in Windows terminal.
There's probably an easier way (even if WT is the default), but the likes of this should start TCC in a console.
c:\Windows\System32\conhost.exe d:\tc32\tcc.exe
Not here. I just spent about 20 minutes trying various GLOBAL commands (in/out of BTMs, several FFIND commands too) with TCC v32 in Windows Terminal. I didn't count but I reckon I did 30-40 tests. Every time, the command was terminated immediately.
Please give a specific command which you...
I always type the code/endcode tags myself, these, without the spaces: [ code ] and [ /code ]. And there are [ icode ] and [ /icode ] (again no spaces) for inline code; I usually select text with the keyboard and choose those from the dropdown (...) menu.
Can you provide an example, complete and the simpler the better, of something you can interrupt in a console but cannot interrupt in WT? Here, Ctrl-C works the same in WT as in a console. I never use Ctrl-Break.
I built a new 4UTILS in which the timestamp log is off by default. I can turn it on for non-transient, non-pipe shells in TCSTART.BTM. A new ZIP file is in place.
copy "ftp://vefatica.net/4plugins/x64/4utils64.zip"
The info comes from the Win32 API function CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0) (and a couple other functions for stepping through the data). I'm sure Rex is aware of it; TakeCmd.DLL imports it so I reckon it's used somewhere. I suspect @PID and ISAPP are using a much more robust...
In a way ... it's the CD that TCC calls first. But if you don't specify /H, /P, /K, or /F, it tells TCC "I'm not the guy you want" and TCC uses its internal CD. For that reason I'd expect mine to be (a few microseconds) slower.
I'll think about the timestamp log. I prefer it to TCC's...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.