OnBarClose?

[AntiMatter]

Rather basic question, but is there a way I can access when a bar actually closes? I can see e.g. FirstTickOfBar, but this can occur sometime after the previous bar closed.

[NinjaTrader_Lance]

Depending on the bar type you're using you may be able to use PercentComplete

http://www.ninjatrader.com/support/helpGuides/nt7/index.html?percentcomplete.htm

Let me know if I can be of further assistance.

[koganam]

Rather basic question, but is there a way I can access when a bar actually closes? I can see e.g. FirstTickOfBar, but this can occur sometime after the previous bar closed.

(Emphasis mine). That is not possible: they are the same event. The Closing price of the previous bar may be different from the Opening price of the current bar, but the event that closes the previous bar is the one that opens the current bar. You just have to refer to the correct price that you want.

If COBC is false, then Close[1] and Open[0] from the same event can be different. If COBC is true, those prices are displaced one bar back. IOW, if COBC is true, there is no way to access any property of the CurrentBar until it closes, when it immediately becomes the past bar. It can get mighty confusing. Heck, it had me in knots for quite a while, until I figured it out.

[AntiMatter]

Ok thanks, that's a useful post.

When is the the Close generated? At the same time as the FirstTickOfBar on the next bar?

[NinjaTrader_Lance]

Most of the time yes, but not always.

There isn't a way that I'm aware of that would allow you to know when the close was generated aside from performing an operation when the next tick comes in.

[AntiMatter]

Lets take minute price bars as our example. Waiting for the FirstTickOfBar (on the new bar) to generate the close (of the previous bar) results in an unnecessary delay for the data for the close - it can be sometime before the next tick.

Instead, wouldn't it make sense to generate the close at the start of the next minute (e.g. 00 seconds)? Or is there something here I am missing?

[NinjaTrader_Lance]

If calculate on bar close is set to true, a trade could not be executed until a new tick of data comes through, thus creating a new bar. If COBC is set to false you would have the value of the close based on the most recent tick.

If you would like I would be happy to submit your request to development.

[koganam]

Lets take minute price bars as our example. Waiting for the FirstTickOfBar (on the new bar) to generate the close (of the previous bar) results in an unnecessary delay for the data for the close - it can be sometime before the next tick.

Instead, wouldn't it make sense to generate the close at the start of the next minute (e.g. 00 seconds)? Or is there something here I am missing?

On the face of it, a very sensible idea. The only caveat is that we are then way too dependent on the accuracy of the computer clock. All clocks drift, so such a method will probably mean that we essentially have charts that cannot be replicated/compared between computers.

[AntiMatter]

Hmmm yes interesting point.

The problem from my perspective is that I am trading on minute data. At the close of the minute, I actually have all the data I need to make a decision about the trade. However, on some of the thinner markets that I trade, the next tick can take quite some time. Thus, if I use FirstTickOfBar (or any of the related variables) then I am entering the trade with a rather unnecessary delay. This may well increase my frictional costs by some (small) margin.

Thus, I need a workaround.

One way would be PercentComplete. However, one issue I have with this is the inability to back test - something I do extensively with new versions of my scripts to confirm that they behave appropriately.

Could an alternative be to look at the seconds, and when we reach 00, I know that the current/last bar is *effectively* closed (with the above caveat about clock asynchrony), even though we may not have received the FirstTickOfBar yet?

[NinjaTrader_Lance]

If you're looking to backtest you would need a smaller time frame to more accurately execute trades. In a backtest COBC is always set to true.

You can add the smaller time frame through the use of Add() http://www.ninjatrader.com/support/h...nstruments.htm

However you may want to look into using market replay and live SIM trading for your testing since historical data only provides the OHLC values.

http://www.ninjatrader.com/support/helpGuides/nt7/index.html?market_replay.htm

http://www.ninjatrader.com/support/helpGuides/nt7/index.html?discrepancies_real_time_vs_bac.htm

[koganam]

Hmmm yes interesting point.

The problem from my perspective is that I am trading on minute data. At the close of the minute, I actually have all the data I need to make a decision about the trade. However, on some of the thinner markets that I trade, the next tick can take quite some time. Thus, if I use FirstTickOfBar (or any of the related variables) then I am entering the trade with a rather unnecessary delay. This may well increase my frictional costs by some (small) margin.

Thus, I need a workaround.

One way would be PercentComplete. However, one issue I have with this is the inability to back test - something I do extensively with new versions of my scripts to confirm that they behave appropriately.

Could an alternative be to look at the seconds, and when we reach 00, I know that the current/last bar is *effectively* closed (with the above caveat about clock asynchrony), even though we may not have received the FirstTickOfBar yet?

I guess you should then put a clock display on the chart, and maybe change the background for a few seconds to either tell you that the 00 is coming up and/or has been and gone for a few seconds?

[AntiMatter]

Yes, I definitely need something within the script to tell me when we are in the "grey zone" between 00 and FirtTickOfBar. In this grey zone, I have to temporarily utilise my <I>effective</I> close, because the actual close is not yet available. When the FirstTickOfBar happens, I can then go back to using the actual close (although they could differ....)

In fact, NT or the data provider must have the close information stored until the FirstTickOfBar, right? Would it be possible (potentially in future versions) to access this?

[NinjaTrader_Lance]

Unfortunately this is not possible since the bar would not have closed yet within our framework at all. There's nothing time based driving the bars, all event.

You would need to develop a custom timer that tracked time since the last tick if you wanted to submit an order before the next tick came in after X amount of time passed.

[AntiMatter]

Further to my above posts, to implement what I want, I need access to the time (in seconds) on historical data.

ToTime(DateTime.Now) --> This gives me the time in seconds, but is always the clock time (e.g. when in market replay, it is still the real time).

ToTime(Time[0]) --> This gives me the bar time (e.g. correct for historic data), but only gives one minute resolution e.g. always 105100, wherever we are in the bar.

How can I get second resolution?

[NinjaTrader_Lance]

Hello,

You can use

Time[0].Second to get the second only

Let me know if I can be of further assistance.