Is there a reason why you're so rude? Normally people who discuss a topic handle it in a mature way, without resorting to personal attacks and insults. Makes me wonder why you're hostile about charting platforms?! Of all things?!
In general, the concept of price-bar is used to summarize price-action on a given "interval". Using price-bars of a given interval implicitly assumes you don't need the inner details of price-action, else you choose a smaller "interval". Assuming you have made the right choice of "interval", the best place to make a trading decision is at the end of this interval, ie. once the bar completes, since it is the only time that particular bar is providing you all the information it is meant to. When you issue an order on that bar complete, it is filled by NinjaTrade backtesting engine at the open of the next bar of the timeframe you choose for the fill engine. I contend that the 1-sec timeframe is the most appropriate for this in backtest, as it implicitly provides some delay between your trade decision & the order fill, which delay naturally occurs when trading live (network delay, matching engine queue delays). Besides, at the retail level, there is no chance that your historical data doesn't have some jitter vs. what you would have seen in real-time. Just accept that at the retail level, 1-second is precise enough for backtesting purpose. Would you care providing an example of a real-time trading decision that needs to be done intra-bar?
Thanks for the reply. Again, the problem comes down to expertise. From your posts, you're either an experienced or professional programmer. Yes, NT can reference multiple timeframes to enter on next 1 sec bars. But this requires extensive programming, from what I hear. Like pages of code. This is not possible for a newbie. An example - buy at market when current candle trades below prior candle by 5 ticks. Say it's a 5 min timeframe. And lets also say the current bar trades below the prior bar by 20 ticks, and then closes. Using one timeframe on NT, the entry would be calculated on next bar open = ~15 ticks away from the original, intended price had the strategy entered in real time. Now, to get a pseudo real time market entry, a NT programmer has to 1) reference multiple timeframes and 2) reference a 1 sec time frame and build entries from candle closes on that timeframe, which again, given the enter at candle close/next candle open, are problematic, as demonstrated. This is a huge sticking point.
Here is how I would address your example: - main TF : 5-min per your example - second TF : 1-sec TF ... used for order-fills, & real-time trading actions On the main TF, on bar close, you make the decision to go Long at market on a print 5-tick below that bar low. Keep track of that decision & the associated price-level. On the 1-sec TF, on bar close, when the current bar Low reaches or exceeds the selected price-level, issue your Long @ MKT, which will be filled at the open of the next 1-sec bar (essentially, at or near the Close of that 1-second bar). From a timing point of view, this gives you at most a 1-second delay between the price-print & the order-filled. Is this perfect? No, of course. But over a hundred trades, the impact of that 1-second delay will average towards zero (IMO). One more comment re. historical data - a couple years ago, when I was considering buying historical data from TickData, I did review all differences on CL over a 3 days timespan (~ 600k transactions) between the data I had captured live from IQFeed, and their data. I found very few price / volume differences (some of which being mis-ordered), but I found that a small % of all transactions had a 1-second difference in their timestamp, and it was always the TickData transaction which incurred that 1-second delay. This can be easily explained by a larger latency to the TickData server-farm than to my own VPS, my point being, even with good quality historical data as TickData provides, you'll be facing this kind of (minor) issue.
In terms of complexity, this particular example would be extremely easy to program, I would say max 10 lines more for the suggested approach, vs. using a single timeframe with CalculateOnBarClose=false (which we both know cannot be backtested in NT7 - it will be possible to backtest in NT8, but with a lot of added CPU computation time, as that will take processing all transactions in backtest - a nightmare for ES).
What exactly do you dispute about what I said? I'm open to suggestions. You're just reactionary and emotional. Try and calm down a bit.
Don't forget to read these forums in light of who writes what; people like to spread misinformation... something that bothers me!