how update file txt

turbofib · Aug 02 2024

hi,

i want to write the signal entries into a file (.txt) every day
I use Print(File(name),"entry",entry) to write the entries signal into the file
The next day I want to open that file and update it with the new entry signals

how can i do it?

Polly MultiCharts · Aug 05 2024

Hello turbofib,

You can use FileClose(Path); for that:

Code: Select all

var: IsSessionlastbar(false);
var: IsSessionFirstbar(false);
var: Path("f:\Download\download\data1.txt");

IsSessionlastbar = sessionlastbar;


if IsSessionlastbar[1] = true then
begin
	IsSessionFirstbar = true;
end
else
begin
	IsSessionFirstbar = false;
end;

if IsSessionFirstbar then
begin
	FileClose(Path);
end;

Print(File(Path), Symbol_CurrentBar, " ", close);

turbofib · Aug 15 2024

Hello turbofib,

You can use FileClose(Path); for that:

Code: Select all
var: IsSessionlastbar(false); var: IsSessionFirstbar(false); var: Path("f:\Download\download\data1.txt"); IsSessionlastbar = sessionlastbar; if IsSessionlastbar[1] = true then begin IsSessionFirstbar = true; end else begin IsSessionFirstbar = false; end; if IsSessionFirstbar then begin FileClose(Path); end; Print(File(Path), Symbol_CurrentBar, " ", close);

hi, i add this piece of signal to strategy
(I ran this signal live (not backtesting)

mp_brok=MarketPosition_at_Broker_for_The_Strategy;
if mp_brok<>mp_brok[1] and mp_brok<>0 then begin
Print(File(fullFN),Date2String(date)," ",time," ",AvgEntryPrice:0:5," ",AvgEntryPrice_at_Broker_for_The_Strategy:0:5," ",mp_brok:0:0," ",mp_brok[1]);
end;

I see in File:

15/08/2024 900.00 5530.75000 5531.25000 1 0.00
15/08/2024 900.00 5530.75000 5531.25000 1 0.00
15/08/2024 900.00 5530.75000 5531.25000 1 0.00
15/08/2024 900.00 5530.75000 5531.25000 1 0.00

Why it's repeat 4 time?
In pics there is the signal (1 signal for all day)

Immagine.png: (2.08 KiB) Not downloaded yet

Polly MultiCharts · Aug 16 2024

turbofib,

Please make sure you’ve added FileClose() in the script. For example like here:

Code: Select all

if mp_brok <> mp_brok[1] and mp_brok <> 0 then
begin
	Print(File(fullFN), datetimetostring(datetime), " ", AvgEntryPrice:0:5, " ", AvgEntryPrice:0:5, " ", mp_brok:0:0, " ", mp_brok[1]);
	FileClose(fullFN);
end;

turbofib · Aug 16 2024

If there are several signals in a session do you have to write fileClose on each signal?

Polly MultiCharts · Aug 16 2024

turbofib,

An access error might occur when two signals try to access the same file, so it’s easier to write to two different files or implement logic with global variables that will open the file one after another and write to it.

turbofib · Aug 21 2024

turbofib,

An access error might occur when two signals try to access the same file, so it’s easier to write to two different files or implement logic with global variables that will open the file one after another and write to it.

Hi, Poly
I execute 2 signal
1 signal sell and 1 signal buy

code is that:

mp_brok=MarketPosition_at_Broker_for_The_Strategy;

if mp_brok<>mp_brok[1] and mp_brok<>0 then begin
Print(File(fullFN),Date2String(date)," ",time," ",AvgEntryPrice:0:5," ",AvgEntryPrice_at_Broker_for_The_Strategy:0:5," ",mp_brok:0:0," ",mp_brok[1]);
FileClose(fullFN);
end;

File .txt :
21/08/2024 1145.00 5628.00000 5627.75000 1 -1.00

I see printed only signal long
why? i have other strategy in Multichart live but if i use MarketPosition_at_Broker_for_The_Strategy i get marketposition only about this strategy..is correct?
(The broker had zero positions for that strategy at the opening of the session so the mp_brok<>mp_brok[1] had to execute it correctly)

I have a doubt...
Does it show me the second signal because it overwrote the file and therefore deleted the first signal?

Mark Brown · Aug 28 2024

i know more about this subject than anyone on planet earth including anyone at mc.

it is impossible to execute trades using print to file because like you discovered it does not append it OVERWRITES the entire file every time any data is added to the chart.

any attempt at monitoring the file will be futile because it rewrites the same exact data over and over again.

i have used python to monitor the mc file and attache a barnumber or uid to each and everybar. then tell python to make another file and only put unique occurrences appended to the python created file.

The problem involves MultiCharts (MC) continually rewriting a text file, which is intended to be used for logging trades or signals. The repetitive rewriting by MC can cause issues when trying to manage or execute trades, especially when an external system (like a Python script) is monitoring the file for new trade signals. Here’s a detailed explanation of the issue and the solution involving a separate file managed by Python:
The Problem with MultiCharts Rewriting the Text File

Continuous Rewriting by MultiCharts:
MultiCharts is designed to log trade signals or other data to a text file. This text file is continually updated with new data. However, MC's behavior involves rewriting the entire file or frequently updating it with the latest information.
This frequent rewriting can lead to redundancy where the same trade signals are repeatedly written to the file. As a result, the file might show multiple entries for the same trade or signal, creating confusion.

Issues with Monitoring:
If an external system, like a Python script, is set up to monitor the MC text file for new trades or signals, it may interpret each rewrite or repeated entry as a new signal.
This can lead to the Python script executing the same trade multiple times or misinterpreting the data, leading to errors in trading or analysis.

The Solution Using a Separate Python-Managed File

To address this issue, a two-file system is implemented, where Python maintains a separate file. Here’s how it works:

Primary File (MC Output File):
This is the original text file that MultiCharts writes to. It contains trade signals, bar numbers, timestamps, and other information as generated by the trading strategy in MC.
Due to the rewriting nature of MC, this file may contain redundant or repeated entries.

Secondary File (Python-Managed File):
A separate file is maintained by the Python script, distinct from the MC output file. This file is used to keep a clean and accurate log of trades that have already been processed.
Python reads the MC output file, identifies new entries (based on unique bar numbers or other criteria), and then writes these entries to the Python-managed file.

How the Solution Works

Reading and Monitoring:
The Python script continually monitors the MC output file for changes. It reads the entries and looks for new, unique bar numbers or trade signals that haven't been processed yet.
The script keeps track of the last processed bar number or trade signal, ensuring that it doesn't react to the same entry multiple times.

Logging to the Python-Managed File:
When a new and unique bar number or trade signal is detected, the Python script writes this information to its own managed file.
This secondary file acts as a log of trades or signals that have been processed, ensuring that each trade is only executed once per unique bar number or condition.

Execution Control:
By using the Python-managed file, the script can control the flow of trades more accurately. It ensures that only valid, new trades are executed based on the latest signals.
The use of a separate log allows the script to handle trade execution logic (such as avoiding multiple trades for the same bar) independently of the MC output file’s rewriting behavior.

Benefits of the Two-File System

Prevents Duplicate Trades: By checking for unique entries, the Python script ensures that trades are not duplicated, even if MC writes the same signal multiple times.
Improved Stability: The Python-managed file provides a stable reference that doesn’t change or get overwritten, unlike the MC output file.
Enhanced Control: The script can implement more sophisticated trade management and logging, ensuring compliance with trading rules and avoiding errors.

Conclusion

The problem arises from MultiCharts' frequent rewriting of the output file, which can cause the external system to misinterpret signals. By using a Python script to manage a separate log file, we can filter out redundant signals, maintain accurate trade records, and ensure that each trade is executed correctly and only once per bar number or trading condition. This approach mitigates the issues caused by MC’s rewriting behavior and allows for reliable automated trading or signal processing.

Mark Brown · Aug 28 2024

TJ · Aug 28 2024

File print is a Windows operation. I doubt MC can do much about it.

Mark Brown · Aug 28 2024

File print is a Windows operation. I doubt MC can do much about it.

actually it's mc sending the data to the file not ms the file append should be renamed file resend lol

turbofib · Aug 30 2024

this print occurred in 2 milliseconds. yet my bar size is 10 points kase bars.

take a look at this xxxxxx print log NOTICE: the miliseconds stamp on the entries. think how much system resources are being used because mc does not handle file print properly.

i would not even be using file print if the auto trading worked. just like file print auto trading will give duplicate trades caused me much personal loss of real money.

the promise of auto trading using mc is not true at all. at best its a manual trading platform.

DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.300 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.301 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.301 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.302 | Condition: Buy Long | Bar Number: 96
DateTime: 2024-08-28 00:09:53.303 | Condition: Buy Long | Bar Number: 96

Thank Mark For answer
you write " i would not even be using file print if the auto trading worked. just like file print auto trading will give duplicate trades caused me much personal loss of real money. "

How do you recommend encoding the file output to avoid this? Can you give a code example for mc's print file?
I use 5 minute chart so I would have live orders every 5 minutes (and therefore row writes would be done every 5 minutes)

Mark Brown · Aug 30 2024

i would write the file out as you wish - aware that every new tick of data the file will be totally rewritten by mc.

i use python watchdog to monitor the file and then my script writes out a sister file of it's own with a different name that mc can not touch. python parses the data as it comes in and only writes out to its file new information when it recognizes it as actually being new.

then the script acts on that new data and bring ms to to front focus to execute trades using hotkey mapping that i have done in mc.

kinda complicated but it works.

The provided Python script uses the watchdog library to monitor a file for changes. It reads the latest data written by MultiCharts, processes this data, and writes it to a different output file if the data is new. This ensures that only genuinely new information triggers further actions. Here’s a step-by-step explanation of how the script works and some practical tips for using it effectively.
Breakdown of the Script

Imports:
watchdog.observers.Observer and watchdog.events.FileSystemEventHandler: These are the core classes from the watchdog library that enable monitoring of file system events.
time: This is used to pause the main thread to keep the script running and checking for changes.

DataHandler Class:
Inherits from FileSystemEventHandler to handle file system events like file modifications.
Attributes:
monitored_file: The file that MultiCharts writes to. This file is monitored for changes.
output_file: The sister file where new data is written by the script.
last_line: Keeps track of the last processed line to avoid processing the same data repeatedly.
Methods:
on_modified(event): This method is called whenever the monitored file is modified. It checks if the file that was modified is the one being monitored and reads the latest line.
process_new_data(line): Handles the new data. In this case, it appends the new line to the output file and can include logic for trading actions.

Main Execution:
The script sets up file paths for the monitored file and the output file.
An instance of Observer is created, and the DataHandler event handler is scheduled to monitor the specified directory for changes.
The observer is started to begin monitoring.
A try block keeps the script running, allowing the observer to continue monitoring. The except block handles keyboard interrupts (e.g., pressing Ctrl+C), which stops the observer gracefully.

Usage and Practical Tips

Specify File Paths: Replace "path_to_mc_output_file.txt" and "path_to_python_output_file.txt" with the actual file paths where MultiCharts outputs data and where you want the processed data to be written.

Set Monitoring Directory: In the observer.schedule() call, replace "path_to_watch_directory" with the path of the directory containing the monitored file.

Add Trading Logic: In the process_new_data() method, you can include additional logic to bring MultiCharts to the front and execute trades using hotkeys. You could use libraries like pyautogui to automate key presses, or subprocess to run specific scripts or commands.

Error Handling: Consider adding more robust error handling in the on_modified() and process_new_data() methods to handle issues like file access errors or malformed data.

Performance Considerations: If the monitored file updates very frequently, you may need to optimize the script to handle high-frequency data updates without missing events or overloading the system.

Testing: Test the script with sample data and ensure that the file paths, trading logic, and hotkey interactions work as expected before using it in a live trading environment.

Example Adjustment for Real-World Use

Here’s how you might adjust the file paths and add a simple placeholder for trading actions:

from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler
import time
import pyautogui # Example library for automating key presses

class DataHandler(FileSystemEventHandler):
def __init__(self, monitored_file, output_file):
self.monitored_file = monitored_file
self.output_file = output_file
self.last_line = None

def on_modified(self, event):
if event.src_path == self.monitored_file:
with open(self.monitored_file, 'r') as file:
lines = file.readlines()
if lines:
new_line = lines[-1]
if new_line != self.last_line:
self.last_line = new_line
self.process_new_data(new_line)

def process_new_data(self, line):
# Parse the new data and write it to the output file
with open(self.output_file, 'a') as file:
file.write(line)

# Placeholder for bringing MultiCharts to front and executing trades
pyautogui.hotkey('ctrl', 'alt', 't') # Example: Trigger a hotkey combination

if __name__ == "__main__":
monitored_file = "C:\\path\\to\\mc_output_file.txt"
output_file = "C:\\path\\to\\python_output_file.txt"
watch_directory = "C:\\path\\to\\watch_directory"

event_handler = DataHandler(monitored_file, output_file)
observer = Observer()
observer.schedule(event_handler, path=watch_directory, recursive=False)
observer.start()

try:
while True:
time.sleep(1)
except KeyboardInterrupt:
observer.stop()
observer.join()

turbofib · Aug 30 2024

ok thanks you
But about the code in mc you use File or FileUppend?
and for each written line do you use CloseFile? (so if the signal writes to me 20 times in one day I open and close the file 20 times)

Mark Brown · Aug 30 2024

i use file append it's all we have for mc

i don't use file close it's useless cause it just keeps updating every tick anyway. maybe for end of day it would be ok.

you are fighting a battle between getting the latest information and getting delayed info. yea it all works after the fact, but in real time battle it fails.

that the whole reason i write it out to a separate copy file to get it away from the machine gunning of mc. yet it also has the most update info. without rewriting every tick.

some of my print logic

Code: Select all

  FileAppend(FilePath, "Summary for " + formattedDate + ": Total: " + NumToStr(totalCount, 0) + ", Highs: " + NumToStr(highCount, 0) + ", Lows: " + NumToStr(lowCount, 0) + NewLine);
    FileAppend(FilePath, "Max Up Streak: " + NumToStr(maxUpStreak, 0) + ", Number of Up Streaks: " + NumToStr(upStreakCount, 0) + NewLine);
    FileAppend(FilePath, "Max Down Streak: " + NumToStr(maxDownStreak, 0) + ", Number of Down Streaks: " + NumToStr(downStreakCount, 0) + NewLine);
    FileAppend(FilePath, "Singular Up Occurrences: " + NumToStr(singularUps, 0) + ", Singular Down Occurrences: " + NumToStr(singularDowns, 0) + NewLine);
    FileAppend(FilePath, "Total UB2 Penetrations: " + NumToStr(totalUB2, 0) + ", Total DB2 Penetrations: " + NumToStr(totalDB2, 0) + NewLine);
    FileAppend(FilePath, "Opening Price: " + NumToStr(openPrice, 2) + ", Closing Price: " + NumToStr(closePrice, 2) + ", Daily Range: " + NumToStr(dailyRange, 2) + ", Day Type: " + dayType + NewLine);

turbofib · Aug 30 2024

ok thanks
Tell me what you think about this idea:

I need to know the trade data when I request it
I thought about connecting Matlab/Phyton to Telegram with a bot
When I make the request via telegram he writes me a word on a text file.
Mc reads the txt file at each update, in this way I ask him for the information I want
What do you think of this as an idea to minimize the writing of the file?
The only thing is that MC must read the file (which will be updated) with each bar update

PeterSt · Aug 31 2024

I see in File:

15/08/2024 900.00 5530.75000 5531.25000 1 0.00
15/08/2024 900.00 5530.75000 5531.25000 1 0.00
15/08/2024 900.00 5530.75000 5531.25000 1 0.00
15/08/2024 900.00 5530.75000 5531.25000 1 0.00

Why it's repeat 4 time?
In pics there is the signal (1 signal for all day)
Immagine.png

The comments and work out from Mark are appreciated, but as often, it is MC which fails here.
@turbofib, your approach is not wrong at all. But MC applies several calls to your code, starting with Create().
At this moment it is still beyond me what happens for real and how real trading would be allowed decently, but as long as I can't grasp this, I say "not". Some examples of this (all verifyable, though with effort (I already spent)) :

- During Optimization for one iteration your initialization code (up to StartCalc) is called several times - at least 3 (max I saw was 9). This happens right at the start - when thee threads for the Optimization are started.
This is all (failing) threading stuff, and it will disallow you to make any logging at all, unless you are able to make the calls to the log file (name !) more unique than date/time up to the best granulation (threads start really in parallel up to the millisecond). Thus, you must be able to have a counter which increases per call of Create(). This is doable with some trickery.

- Mark's solution(s) work because he grabs the added log file lines uniquely. Thus, while your (turbofib) 4 times would be in order because of anomaly, Mark only takes one line of those. NOTE : I see Mark speculating about ticks, but with HFT at the tick level, I don't think his solution can work after all, because the ticks come in with several at the same millisecond (and we don't have more granularity). Thus, you can't discern doubles any more.

- The previous bullet point springs from this one : also CalcBar() is called several times, so far beyond my understanding. I derive this from issues with Exits not working out, trying to capture them in the next bar call, which seems impossible. I mean, after a proven exit command (Market Order - proven by log file), the position stays, and a text in the next bars for not flat in order to solve it in aftermath, only fails (the "how" of that is too hard too explain in text here, but the point is : I can not solve this in aftermath). I could work this out for you with (real) code snippets, but as long as my comments on them make no sense really (yet), it is best to refrain from that.
Please notice that this can be repeated in Backtest (always fails on the same spots - see date/time of the bar) and in Live it fails too - kind of within a few attempts of trade.

- The key takeaway of the above is that you won't notice, because in normal circumstances a next trade command from your code will (coincidentally) not fail, so you just won't know. But you *will* know when you plot the executed trades by you(r program) and see those, without the real thing happening (from Trade Commands - Backtest or Live)
Only when your code contains logic like "I wait from the feedback of the broker before commencing with new trades" you will explicitly notice because nothing happens any more (the previous trade did not go out, and your code keeps on waiting for the confirmation).
Once you know about this, and build in test code (like logging) for this yourself, you will soon start thinking of ditching MC.

All 'n all, and trying to keep On Topic, it is the logging itself which now requires whatever hoopla (like Mark's solution) to report to you in decent fashion. But would you really, knowing that the calls from MC themselves s*ck ? Personally I find it hard to continue with this ...

While working on this, I ran into a mere explicit issue of Optimizations giving 0 (gain) value results. Once you focus on that, you see that it is not a coincidental 0 result, but just no trades occurring. This can't be, so you start to work out that. Again with (undoable) logging. And from there it gets worse and worse.
The 0 results are related to implying more iterations than appointed - or available cores, and again it is the threading system from MC which fails (more than "all over"). It also relates to the output window, hence, don't write so much to that and more iterations will work. Yeah, unbelievable.

Because I too am not from yesterday (I'd like to repeat Mark's words, but I better don't

), I found that freeing a thread from its task for a little while (like 100ms), makes another thread continue. All you need for this is the experience with Single Threaded systems (which simply don't allow to run more processes in parallel), to ever come up which such crap for solutions. But I can and I do.
I now have such small Sleeps active at 4 places, because things otherwise simply won't work.
And please not to forget : I work with 1-tick bars exclusively, and not doing that will hide most of the issues.

I think I mentioned it elsewhere too : just make yourself a trading system which just dives in regardless (e.g. go Long at the first call), do this in Live or else you won't notice a thing, and start frowning why nothing happens, and try to reason out that when it finally happens, why that is.
It is all MC mystique which originally was intriguing for me, but which by now only leads to failing trades. I think Mark said it too : it leads to losing money (while backtesting shows nothing of that).

All 'n all it is sad that just because you make logging to get hold of all what's happening, that logging itself shows all the numerous (yes) anomalies which are beyond you and for which you can only guess the reasons. It looks a lot like like my own attempt for the solution of a missed trade while the command was given, which attempt to do it again in the next bar call. Thus, as if MC herself applies this backdoor trick too.
Please notice and disclaimer : for Live I can (theoretically) reason this out to some too busy core somewhere, which even could be told by alert (yellow box), but since it happens with Backtesting just the same, what to say.
To picture this, envision a backtest of one week with something like 200+ trades each day (thus 1000 full trades) and dozens of them are just not executed for real (never mind it is backtesting) which you will never know, unless you built in logging for it (or Output.WriteLine (in.Net)).
Although this is an issue in itself, it should not turn into the issue of this topic/thread. But point remains : it is logging which we try to apply to solve issues like mine, and now it is right on topic ...

Go figure : yesterday I talked through a design which would be able to uniquely identify the separate calls from the separate threads during optimization. Yes, this is the very same issue which is addressed in the Global Variables thread/question from Kate. It seems doable, but it still does not address the double calling which also occurs in there (thus, not only in backtest but also during optimization). I suppose I can get hold of a Windows PID (Program ID) for the threads, but I expect this to be cumbersome because it can be expected that this changes along the way because of the several stages of an optimization. What about : maybe I have better things to do.