Thank you for making it possible to run Zorro in training mode, unattended via the command line.

For compile errors which can be caused by my strategies or Zorro bugs, Zorro sometimes stops and produces a modal dialog box that can only be dismissed by the human user.

This is not compatible with automation.

All modal dialog boxes normally require a user reaction. Otherwise they weren't modal.

Messages that do not require immediate user attention appear in nonmodal dialogs or in the message window.

I have a dos/cmd/batch script which executes Zorro -train at the command line, say 1000 times, with a different strategy each time. If one of the strategies has an error, the remainder will not execute. Zorro will block and wait for me to click on something. I would rather Zorro just log the error and exit so the batch script can continue and as much work as possible will be completed without my intervention. I can deal with the errors at the end.

Do you follow me?

Not really. If a strategy has an error, you normally would fix it - automation or not. What kind of error are you getting?

Compile error.

I am automatically generating strategies. Sometimes this produces code that Zorro doesn't like, and Zorro produces a compile error either in Train or Test phase. This can be an error in the strategy code or in Zorro. When this happens, I'll segregate the broken strategy for further inspection -- maybe post a bug about it here, if it's compelling. Or, discard it. But the only reason this requires immediate attention from me is because Zorro blocks with a dialog box and does not exit.

I have employed an AutoIt script which just clicks Abort every time that box comes up.

I tend to agree with GPEngine that Zorro suddenly switching from noninteractive (auto) mode to interactive (click is needed) is not very nice. I've not seen much problems with it so far, but I've also occassionaly seen popups that didn't make much sense.

Here's an idea (that might also help GPEngine's case), if command line switch is used (-train in this case), behave non-interactively and just die with an error message (exit status?) if some fatal error is encountered. Don't ask for user assistance, because the user might not be near, that's why -train was used (probably Zorro was called from another script).

OTOH, if Train button is clicked, the operator is probably still near, so continue asking for help/direction with popups when needed (in case of an error, etc...).

This approach could bring the best of both worlds, IMHO.

This is a good idea - when started by command line, suppress message boxes.

Still, I'm interested in some example that produces such an error - it should not happen.

Great!
Watch this forum for more example scripts. In my last update of the PERCEPTRON thread, I mentioned that if all the input signals are poor, adviceLong(PERCEPTRON,...) will produce .c file with a syntax error. (Containing something like "if( > 0.50)". Kaboom.)

In the meantime, consider that other failure modes also produce message boxes. These are two I've seen.
Error 049: Too many trades
Error 060: memory fragmented

Thank you for acting quickly and implementing this feature in 1.16.

The -quiet flag is great.
One more request. Can you also make it so that when -quiet is supplied, the Zorro UI window does not take focus?

For example, I execute a script which starts many Zorro quiet-ly in succession. I cannot get other work done because every time a new Zorro starts, the other window I'm working on goes into the background.