BarsType.Add method - how to always detect if (bars.Count == 0)?

[jdfagan]

I know that this is unsupported by NinjaTrader team, but if NT support can provide any help/hints, it would be appreciated as I'm trying to get some custom bar type code working in NT7. Otherwise, other NT7 custom bar type coders out there, if you have any ideas I'd love to hear them.

So, I'm getting some inconsistent behavior on always being able to reliably detect that bars.Count == 0 from within BarsType.Add method. I had assumed that I would get this if block to always enter per reloading or just loading of a chart. But It seems I can only get it to happen once (perhaps once per from/to combination, not sure yet what drives NT7 calling the Add method - I assumed per tick fed into my chart). For example, after compiling a new variation of my bars type, restarting NT7, and loading up exact same chart with same from/to periods, the bars.Count is automagically greater than 0 to my surprise already (as if the prior NT7 run has cached the generated bars and is not re-calculating them with potentially updated logic of my custom bar type code).

If it is due to cache, I can see that as beneficial for 99.99% of time, except when you are trying to debug your own bars type code and thus alter logic from run to run . So, if I'm hitting a caching issue, how can I work around it so that after I restart Ninja in between changes to my custom bars type code, it will always hit the bars.Count == 0 logic condition?

Or is there a better way to detect the very first tick from a chart that I want to *ALWAYS* detect for my Tick driven custom bar type within the Add method so I can properly initialize my chart building process?

Here's snippet of code for example - I use Trace.WriteLine (i.e., using System.Diagnostics) so that you can trace code paths within Ninja's trace log files:
Snippet

    public override void Add(Data.Bars bars, double open, double high, double low, double close, DateTime time, long volume, bool isRealtime) {
        Trace.WriteLine([COLOR=#A31515][/COLOR][COLOR=#2B91AF]String[/COLOR].Format([COLOR=#A31515]">>>> bars.Count = {0}"[/COLOR], bars.Count));
        if (bars.Count == 0) {
            Trace.WriteLine([COLOR=#A31515]">>>> building first bar in chart"[/COLOR]);
Snippet            AddBar(bars, open, high, low, close, time, volume, isRealtime);
        } else {
            Bar bar = (Bar)bars.Get(bars.Count - 1);
            ...
        }

JD

[NinjaTrader_Bertrand]

JD, for the cache, please try exiting NT and deleting the cache folder contents under MyDocuments\NinjaTrader 7\db\cache for the session template you would use on your custom type - then restart NT and recheck. Would that help you out?

[jdfagan]

thanks, but bars.Count == 0 gets hit multiple times per chart due to auto-merging..

Thanks Bertrand! That does indeed help me. I can now get it to hit bars.Count == 0 again .

One thing I've noticed is that it seems that NinjaTrader creates a new instance of my custom BarsType class per "rollover" contract within a single chart which auto merges into a single virtual continuous contract behind the scenes. For example, FDAX chart spanning from 5/28/2010 thru 6/24/2010 would hit the if logic of bars.Count == 0 twice! Once for FDAX 06-10 and once for FDAX 09-10 (the second one being around 6/17/2010 which is about the rollover date for FDAX from June to September contracts).

Is there a better way for me have the code work at the "MasterInstrument" level of FDAX instead of the component contract levels of FDAX 06-10 and FDAX 09-10?

This is messing up my logic at boundaries of rollover from one contract to the next (happening in middle of my visual chart). I need to reliably reference prior bar built from a chart even if it was derived from a previous contract. I don't want the code dive into bars.Count == 0 condition in middle of my chart - only want that effect at start of my chart. But current NinjaTrader BarsType design is preventing this. My only recourse seems to be for me to use a static Dictionary keyed by Thread + MasterInstrument to be able to reference my own state variables across rollover boundaries.

To demonstrate that this is happening on one single chart, here's snippet of trace output where I spit out when bars.Count == 0 is happening from within my Add method with from/to dates spanning from 3/1/2010 thru 6/24/2010 against FDAX 09-10 (which relies upon Global merge policy of MergeBackAdjusted):

2010-06-29 11:44:59:506 >> Thread 14 << Count == 0: MasterInstrument.Name = FDAX, bars = instrument='FDAX 03-10' from='2010-02-25' to='2010-03-18' period=5t RenkoNG splitAdjusted=False dividendAdjusted=False bars=0
2010-06-29 11:45:57:715 >> Thread 14 << Count == 0: MasterInstrument.Name = FDAX, bars = instrument='FDAX 06-10' from='2010-03-14' to='2010-06-17' period=5t RenkoNG splitAdjusted=False dividendAdjusted=False bars=0
2010-06-29 11:51:59:421 >> Thread 14 << Count == 0: MasterInstrument.Name = FDAX, bars = instrument='FDAX 09-10' from='2010-06-13' to='2010-06-25' period=5t RenkoNG splitAdjusted=False dividendAdjusted=False bars=0

JD

[NinjaTrader_Austin]

jdfagan, have you tried setting the Merge Policy in Tools -> Options -> Data to DoNotMerge?

[jdfagan]

But I love the auto merging feature of NT7 . Auto-merging makes for very nice way to easily backtest for many months for a single Master Instrument when doing analysis.

Do not merge setting as you suggest would effectively make it not possible for me to analyze charts and run backtests for say 6 months, 12 months, etc. for typical futures contracts.

It would have been a nicer design IMO if there was a 1:1 relationship between a Data Series Start/End date and one's Custom Bar Type class instantiations (at least from a Custom Bar Type developer's API point of view). But it looks like I have to deal with handling many Custom Bar Type objects for one Data Series Start/End period that spans across rollover boundaries.

I'm going to attempt at resolving this issue by storing state info (e.g., prior bar's OHLC data) that I don't want to lose when crossing rollover boundaries by saving this data at the static class level.

JD