Ignored Order

[jg123]

As per the suggestion on Post #6, I have tried the following, but this is making everything all messed up. Therefore I want to make sure that I am on the right track before I start working through trying to debug it. I am really confused as mentioned in my last post so it makes it really difficult to know if I am taking things in the right direction or not. If anybody is able to help clear up the confusion that I have written about in the last one, that would be really beneficial!

Here is the code that I have written in OnOrderUpdate;

		protected override void OnOrderUpdate(IOrder order)
		{
			if (LongLimit != null
				&& LongLimit.OrderState == OrderState.Filled
				&& LongAdjustedStop == null)
			{
				SubmitAdjustedStop = true;
			}
		
		}

That is supposed to set the bool value to the true if LongLimit gets filled. Then, in OnBarUpdate I have written this:

				if (SubmitAdjustedStop == true
					&& LongAdjustedStop == null)
				{
					LongAdjustedStop = ExitLongStop(0,true,positionSize,adjustedStopLong,"LongAdjustedStop","LongEntryB");
					SubmitAdjustedStop = false;
				}

And now all of the trades are really messed up. Granted it could be a debugging issue that I need to work through and am happy to do so, but I just need to know if this code is in line with what Cal has mentioned before I go on and start working through to find the bugs.

Thank you very much for your continued help. It is very beneifcial for me!

[jg123]

Hello

Just checking in to see if there is an update on this. I haven't heard from anyone in a couple of days.

Thanks.

[NinjaTrader_PatrickH]

Hello jg123,

Thank you for your patience.

The adjustedStopLong price that is used is calculated on the fill of the LongLimit as you intend it to be:

adjustedStopLong = LongEntryB.AvgFillPrice - (TargetPriceLong - LongEntryB.AvgFillPrice);

However, that price level is submitted for the LongAdjustedStop order when the LongLimit fills. When the LongLimit fills the last bar is the preceding bar and thus the rejection. This would only be the case in historical testing as real-time would have the current bar's price levels.

To work around this in historical testing you could use BarsSinceEntry() and ensure one bar has passed before submitting the Stop order: http://www.ninjatrader.com/support/h...sinceentry.htm
Or submit the LongAdjustedStop in OnBarUpdate(), so that the bar has closed when you check for the fill of the entry order state.

[jg123]

Thank you very much Patrick.

This did help to clear things up. I am still not too sure why things happen 1 bar beforehand - but I guess that is just something to know going forward.

Will NinjaTrader 8 operate in the same way?

[NinjaTrader_PatrickH]

Hello jg123,

Thank you for your response.

NinjaTrader 8 will feature a New Tick Replay Engine that will allow you to view the sequence of events that built the bar, this is an optional function available for NinjaScript as well as an enhanced fill engine for backtesting.. You can view the Major Enhancements document at the following link: http://www.ninjatrader.com/downloads...njaTrader8.pdf