Tweet
OnBarsReceived is called when backfill from the tic/history servers arrives.
OnBarsChanged is called when a quote updates bar 0.
Releasing the handles in one or both of those doesn't generally make sense, if you close it in OnBarsChanged for instance (which will start getting called right away, before even backfill comes, if the stock is active), then you won't (or shouldn't) be able to get any backfill for that handle. Prior to 7.5, doing this sort of thing would likely crash eSignal, I've added some smarter code to handle this since then.
So, it's not really an issue of can or can you not do this, it's just that if it were a real application, it would be silly to do this.
For the lExpectedHandle, it's again just a demonstration of what one ought to do in a real application, which is keep track (on your own) which handles correspond to which requests you've made. Though I've striven to stop this, one may still get events on handles that you've released, so you only want to deal with events that you are expecting. Likewise, if you tried to run two copies of your application, they will both get the events for each other's requests, another reason to only handle events on handles that you personally requested.
As for the symbol stuff, you can request history updates on more than one symbol at a time, as long as you are careful about keeping track of what response is for what symbol etc. We have test applications that download history from 100+ symbols at the same time.
As an aside, the reason your problem didn't get resolved until now is that your usage pattern is different (not better or worse) than what most users of the desktop API do. Generally, people get the maximum amount of data they can in one request and do stuff with it, rather than requesting 10, 20, 30, 40, 50 bars on the same symbol in sequence.
That bug has been fixed, one should now reliably get an OnBarsReceived corresponding to each request made, even if that request didn't result in an actual query to the servers.
Cheers,
Simon.
OnBarsChanged is called when a quote updates bar 0.
Releasing the handles in one or both of those doesn't generally make sense, if you close it in OnBarsChanged for instance (which will start getting called right away, before even backfill comes, if the stock is active), then you won't (or shouldn't) be able to get any backfill for that handle. Prior to 7.5, doing this sort of thing would likely crash eSignal, I've added some smarter code to handle this since then.
So, it's not really an issue of can or can you not do this, it's just that if it were a real application, it would be silly to do this.
For the lExpectedHandle, it's again just a demonstration of what one ought to do in a real application, which is keep track (on your own) which handles correspond to which requests you've made. Though I've striven to stop this, one may still get events on handles that you've released, so you only want to deal with events that you are expecting. Likewise, if you tried to run two copies of your application, they will both get the events for each other's requests, another reason to only handle events on handles that you personally requested.
As for the symbol stuff, you can request history updates on more than one symbol at a time, as long as you are careful about keeping track of what response is for what symbol etc. We have test applications that download history from 100+ symbols at the same time.
As an aside, the reason your problem didn't get resolved until now is that your usage pattern is different (not better or worse) than what most users of the desktop API do. Generally, people get the maximum amount of data they can in one request and do stuff with it, rather than requesting 10, 20, 30, 40, 50 bars on the same symbol in sequence.
That bug has been fixed, one should now reliably get an OnBarsReceived corresponding to each request made, even if that request didn't result in an actual query to the servers.
Cheers,
Simon.
Comment