Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Take Command Is Too Fast!

Jun
552
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?
 
Can you post a picture of the toolbar button's dialog so we can see the basic set-up?

Does your second scenario run OK in a TCC stand-alone console?
 
To answer the earlier comments, this had nothing to do with the toolbar button. That's just how I discovered the problem. I could get the same problems to occur in other ways.

Since my original posting, some other code that ran fine under version 25 has been crashing version 27, so there is some issue. For example, sometimes when I run some code to open an application, it opens with focus. At other times, it opens behind TCMD. I have not yet been able to find a pattern.

I did just discover what I think is a real bug in version 27. The same command that runs fine in version 25, fails in 27. I will report that in a separate posting.
 

Similar threads

Back
Top