- Jun
- 570
- 4
Rex, have you ever received a complaint that TCMD/TCC is too fast!
With my new ultra-high-performance computer, I started having problems with a batch file that had always worked perfectly. It still worked fine when run manually, but it failed wildly when run from a toolbar button. TCMD would crash, spitting out the TCC task to a standalone window.
I finally had an idea as to what was happening. I had combined two commands in the toolbar button, a directory change followed by the batch file to perform a complex display of the directory contents. It occurred to me that the directory display might be running too quickly after the directory change, and sure enough, when I added a mere 10 ms delay (delay /m 10) between the commands, the button started working fine.
Then yesterday I upgraded from version 25 to version 27, and an intermittent problem began to appear during the run of TCSTART when a tab opened. My TCSTART includes execution of the drives.btm file that I showed in the forum a while back. The information for drive C appeared with no problem, but I would get a strange error message about a bad command after "D:" appeared on the screen and before its information was displayed. When I looked at the code in the batch file, I saw that all possible drives were being tested with the @ready function and then information was being extracted by various other functions (e.g., @disktotal). Once I added a 10 ms delay after the @ready invocation, the problem disappeared. The C drive probably worked (1) because I was already logged into it and/or (2) because it is an extremely fast solid-state drive. Drive D is a high capacity mechanical hard drive that I use for archiving material. Version 27 was just enough faster than version 25 to allow the problem to occur.
So, do I need to put in a feature request that you make future versions of Take Command slower :-)
More seriously, do you think that it should be necessary to wait after a directory change before accessing the new area, or does this suggest an issue with the design of my computer?
With my new ultra-high-performance computer, I started having problems with a batch file that had always worked perfectly. It still worked fine when run manually, but it failed wildly when run from a toolbar button. TCMD would crash, spitting out the TCC task to a standalone window.
I finally had an idea as to what was happening. I had combined two commands in the toolbar button, a directory change followed by the batch file to perform a complex display of the directory contents. It occurred to me that the directory display might be running too quickly after the directory change, and sure enough, when I added a mere 10 ms delay (delay /m 10) between the commands, the button started working fine.
Then yesterday I upgraded from version 25 to version 27, and an intermittent problem began to appear during the run of TCSTART when a tab opened. My TCSTART includes execution of the drives.btm file that I showed in the forum a while back. The information for drive C appeared with no problem, but I would get a strange error message about a bad command after "D:" appeared on the screen and before its information was displayed. When I looked at the code in the batch file, I saw that all possible drives were being tested with the @ready function and then information was being extracted by various other functions (e.g., @disktotal). Once I added a 10 ms delay after the @ready invocation, the problem disappeared. The C drive probably worked (1) because I was already logged into it and/or (2) because it is an extremely fast solid-state drive. Drive D is a high capacity mechanical hard drive that I use for archiving material. Version 27 was just enough faster than version 25 to allow the problem to occur.
So, do I need to put in a feature request that you make future versions of Take Command slower :-)
More seriously, do you think that it should be necessary to wait after a directory change before accessing the new area, or does this suggest an issue with the design of my computer?