Limiting the amount of data returned with Bars_Changed event handler

[burtfin]

I'm using the OnBarsChanged event to capture candle data related to calling RequestHistory for five minute candles. I've noticed that the candle data comes across quite a lot during the time the five minute candle is being caculated. This appears to be activity related for each stock.

My question: is there a way to only have the OnBarsChanged event fired at certain intervals in order to reduce the amount of data coming back? I would like to have the data for the candle as it is being caculated, but not anymore that every five seconds.

[AChan]

My understanding is that you are requesting 5 minute historical bars for a symbol using RequestHistory method and you are processing the returning onBarsChanged events. Is this correct? Can you tell us the exact arguments you passed to this call?

If you are only interested in getting historical bars, you can just process the OnBarsReceived events. If you are also interested in getting the updated bars going forward, you can also process the OnBarsChanged events as well.

[burtfin]

I'm interested in both events (OnBarsReceived and OnBarsChanged) for various reasons. Here is an example of how I'm currently calling RequestHistory:

RequestHistory("MSFT", "5", btBARS, 20, -1, -1);

My questions are:

1. How does <number of bars> (e.g., 20) impact the request when the start and end times are -1, meaning the open and close of the exchange?

2. Is it possible to request 5 minute bars with 100 updates/price changes per bar (i.e., OnBarsChanged fires 100 times for each 5 minute bar as the bar is being built)?

I've noticed that for high volume stocks like GOOG the OnBarsChanged event gets fired quite often as price changes happen to the 5 minute bar being developed. I don't need the data more often than 3-5 seconds at a time, but I do want it in the context of the overall 5 minute bars.

Thanks for any additional thoughts,
Burt

[AChan]

1.) We do recommend you to stay with -1, -1 in terms of start time and end time. Number of bars only impact how many historical bars are returned. It's proportional to how many onBarsReceived events are fired.

2.) Unfortunately, there isn't a way to specify how often onBarsChanged events are being fired.

[scheel]

The firing frequency of OnBarsChanged may be ugly, but the exit avenue can be very fast. Just create a global that independently is triggered by an OnTime event to flip a toggle for when you really want to monitor these events. Then, in the event, you examine the global toggle and immediately exit sub if the toggle is off.

This OnBarsChanged event often is an illusion. I've sufficiently documented for my own purposes that it sometimes is fired even when there are no bars!

LOL.

Be happy.

[burtfin]

Yeah, being able to specify a change interval would be cleaner, but I guess I'll have to handle that on my end.

Thanks for the feedback!