Total Commander

The details begins from here: LOADSEARCH does not support UTF-16 text files w/o BOM

[em_addbom]
cmd=%COMMANDER_PATH%\bomfix.vbs

[em_load_search]
cmd=LOADSEARCH saveload_search_in_utf16le_slot_01

[em_addbom_load_search]
cmd=em_addbom, em_load_search

The em_load_search for some reason does not wait completion of the em_addbom, so selects files from the previously generated list file.

I've tried to workaround that by using a `*.bat` script wrapper around the `bomfix.vbs`, but seems the TC itself does not wait completion of previous user command with external script.

This is not really a bug as by design em_cmd are lauched as button :

• when calling an external pgm or batch --> no wait

Works as not expected is sometimes not a bug
You can make a suggestion (or find what have already been asked several times) for a better control of sequence of command or adding a wait in the definition of command/button of with an internal tc batch support !

In TOTALCMD.inc text file or the History.txt
you can find a command:
CM_WAIT <time>=-12;Wait x milliseconds

Maybe try:
[em_addbom_load_search]
cmd=em_addbom,CM_WAIT 500,em_load_search


?

Maybe try:

But may be add new command like:

cmd=em_addbom,CM_WAIT_COMPLETION,em_load_search

to not do such bad workarounds?

andry81 wrote: 2020-11-15, 10:23 UTC

Maybe try:

But may be add new command like:

cmd=em_addbom,CM_WAIT_COMPLETION,em_load_search

to not do such bad workarounds?

What is bad on this method ?
Only your expectations are the fault here.

Horst.Epp,

What is bad on this method ?

It is less reliable and more guesswork than if TC would simply wait for the completion of a command.

Roman

Horst.Epp wrote: 2020-11-15, 13:14 UTC What is bad on this method ?
Only your expectations are the fault here.

To be fair, there is a point there. Having to pre-determine the maximum expected runtime interval of a program invoked is a brittle and unreliable method to ensure sequential execution that doesn't overlap. In short: bad. (Even if it is currently the only built-in method to achieve sequential execution, this method is still bad.)
Now, i agree that this is a feature suggestion and not a bug report. But posting this in the wrong forum section means that the assumption of this being unintended behavior (a bug) was wrong, but that does not really reach the level of the user having outlandish and unreasonable expectations.

"CM_WAIT_COMPLETION" would be not reliable, as the user may execute scripts which starts applications
which inturn launch other processes, and one of the first may report an 'done', but the "child-processes" are still running.
As far as I know you can't monitor the whole process chain, only the first one which you have actually startet yourself.

With "CM_WAIT" each user can test out on each PC which setting may work for him best.



Because TCs chained commands are executed without any check if the command right before
was already finnished, I would just try TCs CM_WAIT to be sure.



 

Stefan2 wrote: 2020-11-15, 14:56 UTC "CM_WAIT_COMPLETION" would be not reliable, as the user may execute scripts which starts applications
which inturn launch other processes, and one of the first may report an 'done', but the "child-processes" are still running.
As far as I know you can't monitor the whole process chain, only the first one which you have actually startet yourself.

No, you can't monitor that without undue effort (well, technically you could in some impractical way possibly requiring admin privileges, see SysInternals ProcessExplorer).
But you can know what your script does and does not do and whether it fire&forgets chiild process. Many scripts/programs don't launch any child processes, and the user can be fully and correctly aware of this -- and yet the user might not be able to confidently and reliably guess execution time (as the actual time of execution can depend on many other factors outside of your program/script.) As such, in many circumstances "CM_WAIT_COMPLETION" would still be substantially more reliable and practical for achieving sequential execution than blindly waiting an arbitrary amount of time which the user has to pre-determine.

(EDIT: Better phrasing...)

"CM_WAIT_COMPLETION" would be not reliable, as the user may execute scripts which starts applications
which inturn launch other processes, and one of the first may report an 'done', but the "child-processes" are still running.

In fact, no, it is a user responsibility to wait all created chirldren processes in case if a user parent process is not the TC itself. In case of the TC the ButtonsBar dialоg along with:

[ ] Run minimized
[ ] Run maximized

can add:

[ ] Await command completion

or add respective builtin command to wait a process created by previous command (see details for the Win32 API `WaitForSingleObject` function).

Because TCs chained commands are executed without any check if the command right before
was already finnished, I would just try TCs CM_WAIT to be sure.

This is ugly practice to use a `wait-with-a-timeout` function to wait initially asynchronous operation. It is definitely unrelaible because based on a race condition between constant timeout to wait a process to close and another timeout of a process itself existence.

Horst.Epp wrote: 2020-11-15, 13:14 UTC Only your expectations are the fault here.

Expectation for a correct behavior is a fault? TC already can execute all the internal commands sequentially, and suddenly, can not do that for an external script. This more looks like a fault to the TC, not a user.

in many circumstances "CM_WAIT_COMPLETION" would still be substantially more reliable and practical for achieving sequential execution than blindly waiting an arbitrary amount of time which the user has to pre-determine.

I very much agree - it is anoying to have to adjust the wait period for all my computers, which have very different processing power - and it makes it difficult to make buttons, or em_commands that can be distributed for puplic use.