There were two initial problems: trades closing unexcectedly and trades opening at incorrect prices.

Your initial response was to reduce the code and follow individual trades in the log to see what the issue is.

I deleted everything then rewrote and rechecked every piece of code by either plotting the results of each chunk on the chart or outputting the results of calculated values, entry prices and takeprofit levels to the log.

Even with the most basic of code, and regardless of what takeprofit and buffer limits are set, if an attempt to make a trade in a certain region in history is made, the trades go haywire (they somehow close or their order price is corrupted).

In order to track the trades, print statements reporting order time, order price, takeprofit levels and the relevant indicator level were added pretty much everywhere prices were calcualted or orders were sent. This is when I found print trades stopped being printed to the log after a repeatedly observable period (though this period differs instrument to instrument). Also, this is where I tried printf(TO_LOG,"nStuff") which results in runtime errors and printf("#n") which also results in dropped print statements.

Enter the TMF. To get around the print statement issue, and to ensure the absolute most correct trade specific data was reported, I employed a TMF that pulls information from the TRADE* of each trade.
Upon sending the pending order, the TradeEntryLimit, TradeProfitLimit and the indicator value at the time of sending the trade are reported by the TMF. As TradeBarOPen and TradeTime for pending orders are reset once the trade is opened, a integer representation of the order send time is calculated and added to #define myDate TradeVar[1]. Also seeing as pending trades do not have a TradeID, a non-repeating random number generator was added (code in is main() ). Trades are assigned a number form the random number array based on total orders sent (manually iterated with each order entry call) and stored in #define myID TradeVar[0].
At order send, the TMF sends the previously generated trade ID (myID), the open price (TradeEntryLimit) and take profit prices (TradeProfitLimit) and the stored previously calculated order send date (myDate).
At order close, the TMF sends again myID, TradeEntryLimit and TradeProfitLimit.

In this way, the TMF replaces allows tracking of trades at stages of their life when they are basically untrackable and allows observation of the time elapsed between sending the pending order and when the order is opened.

The TMF was validated on a small historical period, limiting trading to one open/pending position at a time and then multiple positions, with everything behaving as it should.

However, testing the new code over the original period which was causing problems reveals the three things I previously mentioned. Trades close themselves out unexpectedly, trades open at incorrect prices and printf statements (from the TMF) stop being pushed to the log.
What is interesting, and this is where the TMF comes into it's own, is that by inspecting the log and following the erroneous trades, you can see that at some point between sending the trade and opening the trade, the TRADE* TradeVar[0] and TradeVar[1] lose their values. This does not happen on every trade. There also is no fixed period of time that must elapse between trade send and trade open for these values to be 'lost'.

Regardless of whether using printf on its own or using a TMF to report trade information, the trade distribution and trade 'errors' are the same. I have employed every trick I can think of from my experience with R and MQL4 in order to capture the correct data and ensure the correct data is reported. I have rebuild and validated the code piece-by-piece and still cannot find the problem. I have done extensive coding in R (have run a number of bioinformatics projects along with various financial hacking projects) and have coded countless indicators and strategies in MQL4. A few years back I even fixed the R-MT4 bridge after it was broken by an update to MQL4. But alas, I cannot find what the issue is with this code.

I'm sorry for the long post, but I felt that you should have an up-to-date report on what it is that I've done and how I arrived at the code as it is now. I hope I have demonstrated I am not looking for handouts here but have spent considerable time and energy to find the cause of the issue, only to be no closer than I was at the time of the original post. Having said that, I have become a lot more familiar with various aspects of lite-C and Zorro which I was totally unfamiliar with before so it hasn't been a complete waste of time

Cheers,
BobbyT

Edit: This is all observable on AUDCAD using the period set in the script. Other instruments (not all) display the same behavior at some point in history.