IsHistoryReady not working correctly

[Dierk Droth]

Hi,

In some situation IsHistoryReady says that the history data is ready, but there are 0 bars.

Here is how to reproduce the problem:
- make sure eSignal nor data manager is running
- start your app and make sure any eSignal internal cache is cleared by calling ClearSymbolCache, ReleaseAllHistory, ReleaseAllTimeSales
- request MSFT data for the last 10 days
- release the request handle after recieving the data
- request MSFT data for the last 20 days
- IsHistoryReady will return 1 (= true) but the number of bars is zero

You may try using the attached C# 2003 project.

What's going wrong there ? Am I doing something wrong ?

Regards

[Dierk Droth]

Robi, GenSpoo,

Am I doing something wrong? Or is this an eSignal bug ?

I really would like to know.

Thanks

[Guest]

I am not having the same problem. Anyone else?

[Dierk Droth]

Robi,

Interesting. So, my code sample does not produce the error on your eSignal installation ?

Regards

[Guest]

I ran your code and never run into the code with the MessageBox stating "here is the problem". I always get the next 10 days of data. Why are don't you just request all of the data you want in 1 call, rather than 10, then 20, then 30 days each time?

[Dierk Droth]

Robi,

1) I still can reproduce here.
- press "Go"
- wait for message box "requesting 10 days of data"
- confirm
- wait for message box "requesting 20 days of data"
- confirm
- you'll get the box "this is the problem"

Is this an issue of my installation ? Please advise.

2) I have no influence on how users will execute TradeMagic. It simply has to work in all given scenarios. I easily can forsee scenarios where users apply a calling sequence to eSignal, matching exactely the given one.

Regards

[Guest]

Again, I never the message, "this is a problem". I stopped when I could request 130 days of data.

I am using Windows XP SP2 and C#.NET version 7.1.3088.

[Dierk Droth]

Robi,

Same here: Windows XP SP2 and C#.NET version 7.1.3088

As we now know it's not my sample code, it probably is something with my eSignal installation/configuration/setup.

Please advise.

Regards

[GenSpoo]

I just built and ran the project and I did hit the error. FWIW, I'm also running XP SP2.

It occurs in same place for me, after the 20 bar request.

Cheers... George

[Guest]

I think it stems from the logic in your code. I do not understand why you would do recursive RequestHistory() calls, rather than waiting for the response event of OnBarsChanged(). The problem is that you are making a request, then repeated requests before the event fires back. You should process the response in the event as it is described on page 4-5 of the Developer's Reference before making a new request on the same handle.

[Dierk Droth]

@GenSpoo,
Thanks a lot for trying and confirming this problem. I appreciate that.


@Robi
Not sure if you have the right picture. Please let me try to explain:
1) There is no recursive call of "RequestHistory". These are subsequent calls, any previous call is terminated properly by "ReleaseHistory". The resusiveness of the sample project is just for the sake of simplicity.
2) Looking at the code you will notice that I wait for OnBarsChanged (as you advised). On getting this event I then call "ReleaseHistory".
3) Here is more background info, why this calling sequence is needed:
- After starting TM the user wants to get previous days close. I get this by calling RequestHistory for the last days and looking at the bar before the last one.
- Later on the user wants to request the last year of daily bars, but fails due this bug.
4) I again browsed the development ref doc, but could not find that my code is mal-behaving.

Please advise

[Dierk Droth]

Here is more information:
I installed eSignal and the sample project an another machine. Much slower processor, but same SW setup.

Problem is perfectly reproducable.

Regards

[Guest]

I changed your code to make the problem go away. This may be an issue (a stale value in IsHistoryReady()) when asking for more than 1 request consecutively on the same symbol, however there are plenty of work arounds. We may create an OnHistoryReady() event to compensate.

The scenario you created is somewhat rare and you may need to add additional logic to ensure that you receive bars from the request. A more likely case is that a different symbol is requested and in that case, the IsHistoryReady() method works appropriately. The example shows a way to prevent the false positive on the method from occuring.

[Dierk Droth]

Robi,

Thanks for your research and confirming that bug.

Looking at your workaround:

So you are saying, that - on requesting history - I never should call IsHistoryReady immediately after RequestHistory, but always wait for the OnBarsChanged event ?

Could you please confirm or make corrections is necessary ? You know, I'm looking for a 100% reliable solution. If you want me to use another 100% safe workaround -> please advise.

The docs explicitely hold an example where IsHistoryReady has to be called after RequestHistory first, before waiting for the OnBarsReceived/OnBarsChanged event. I suggest fixing this, since this is opposed to the above statement.

Regards

[Guest]

You do not need to call IsHistoryReady(). You can wait for the even, obtain the number of bars you are to obtain and receive them.

While I offer some technical guidance, I connect assume to understand your programming logic, so you will need to determine what is a reliable solution. You may want to add additional logic to determine if the number of bars received is what you were expecting.