IsHistoryReady not working correctly

[Dierk Droth]

Robi,

1) Thanks, great. So it's safe to wait for the event.

2) On getting the event I will check IsHistoryReady as you suggested by your code changes.
Will I then be 100% safe to see all bars I requested, or do I have to count the bars and probably do some busy wait loops and try again if there are bars missing ?

If the latter is true, how can I make a difference between:
a) There are more bars to be received and I should wait
b) The eSignal server does not have more bars to send. So it would not make sense to wait any longer.

Regards

[Guest]

If you call GetNumBars, it will tell you the number of bars you are to receive. If the number is not the correct amount, based on the time frame and interval, you may need to re-request.

Reliability is interpretted differently for each customer and based on the connection problems you have been experiencing, I don't know how you will achieve 100% reliablity. You may need to perform additional client-side verification tests to reach a level of performance that you wish.

[Dierk Droth]

Robi,

I probably was not clear enough:
- I request 300 bars of daily data (any instrument)
- I get OnBarsReceived/OnBarsChanged events
- calling GetNumBars returns 290

Here is the question:
How can I know that there will be 10 more bars coming in later (so I should wait for more events)? It also could be the case that the eSignal server farms simply does not provide more than these 290 bars back, so it would not make sense to wait and I should just return the 290 bars.

How to make a difference ?

Please understand: it's not a matter of my app or how I code my app or what fail safe checks I will provide on my end. Nor is this scenario related to connection status.

It's about how your API works. IsHistoryReady does not provide the information which is needed (BTW: what is this method then good for?) and waiting does not make sense in all situations as shown in the above scenario.

So what to do ?

Regards

[Guest]

I checked with our developer and what you should do is:

In the OnBarsReceived(), make the IsHistoryReady() call. That event only called when all bars are retrieved.

[Dierk Droth]

Robi,

Thanks for this clear statement. I'll give it a try.

Regards

[Dierk Droth]

Robi,

I just tested. Unfortunately your statement is not correct. There are situations where OnBarsReceived is not called but OnBarsChanged is: just looking at the OnBarsRecieved/IsHistoryReady combination will not work.

You can try on your own:
- open the attached project
- make sure eSignal is not running
- start project and wait until connected
- press "Go"
- after a while you will get a box saying "OnBarsReceived: got data, everything is ok" -> that's ok
- press again "Go"
- no box will popup -> OnBarsRecieved is not called
- set days back to 20 and press again "Go"
- you will get an error message saying "OnBarsChanged: should not happen, numbars = 0" -> same problem as initially reported
- OnBarsRevieced is not called.

The problem still remains unresolved.

Robi, it makes little sense to leave it to your customers trying to find out if and how the API works. Nor does it make sense to put out suggestions which do not work.

There
a) either is a serious problem with the API
b) the documentations does not match the reality and the API has to be used different than documented

Again: This is not a problem of my app, it's just a simple test app here. Nothing fancy. It should not be hard to get the API working as expected.

Please advice.

[sthornington]

New form1.cs

I've changed some things in your C# file here, and it seems to be working correctly now.

Cheers,

Simon.

[Dierk Droth]

Simon,

Thanks for taking care and providing improved sample code.

Unfortunately it's not working.

Try this:
- start project and comment out the eSignal_OnBarsChanged code to get rid of messages which do not matter here (you may try the updated, attached project)
- make sure eSignal is not running
- start sample app and wait until connected
- press "Go" -> you will get the "OnBarsReceived: got data, everything is ok" -> great
- set days back to 20 and try again
- set days back to 30 and try again
...

Sooner or later you will get the error message "OnBarsReceived: should not happen, numbars = 0 instead of 99". It's still not working.

Please advise.

PS: Thanks for the hint on the OnEntitledValid.

Regards

[sthornington]

I've found and fixed a couple of problems in eSignal that were causing this. It was only a problem with daily data, not intraday (which I had done similar fixes for last year).

It will now fire an OnBarsReceived for a request that is satisfied immediately by cached data, as well as reset the 'complete' flag when a request on the same underlying series requires an extension from the server.

In short, it does the same thing as what already happens for intraday data. This should show up in the next (first?) 7.8 beta.

Cheers,

Simon.

[Dierk Droth]

Simon,

Thanks for confirming and fixing this bug. I appreciate that.

Do you have an ETA on when the next (first?) 7.8 beta will be out ?

Regards

[Dierk Droth]

Simon,

I spent some more thoughts on the code changes you suggested some posts below (form1.txt).

In particular I was thinking about:
- the "lExpectedHandle" variable you introduced
- when to call "ReleaseHistory" (you suggested to only call it before the next "RequestHistory" call).

Here is my take:
- Are you suggesting that calling "ReleaseHistory" in "OnBarsRecieved" or "OnBarsChanged" does not really release the history and thus, will not stop eSignal form sending out more events on this handle ?
- Are you suggesting that there only may be one "RequestHistory" call effective at a time ?

As I understand the eSignal API none of the above statements should be true, but then I don't understand why:
- you need the "lExpectedHandle" variable
- you commented out the "ReleaseHistory" call on both events handlers

Would be great if you could shed some light on this issue.

Regards

[Guest]

I think what Simon demonstrated is that you need to receive all of the response events associated to your initial request and can only have one request at a time for each handle.

[Dierk Droth]

Originally posted by eSignal Robi
I think what Simon demonstrated is that you need to receive all of the response events associated to your initial request and can only have one request at a time for each handle.

Robi,

Well, the question is: can I have multiple requests using multiple handles at a time or can I not ?

Regards

[Guest]

You can only have 1 symbol at a time.

[Dierk Droth]

Robi,

Thanks for this clear statement. I appreciate that.

Regards