IsHistoryReady showing wrong value?

[Blomman]

After I installed Esignal v.10.0, IsHistoryReady gets value true immediately after function RequestHistory is called even if the data is not ready. In the example below, NumOfBars always shows 0 after upgrade but worked fine before. Is this a fault or am I doing something wrong?

HistHandle = eSignal.RequestHistory("QQQQ", "1", btBARS, 1000, -1, -1)
If HistHandle > 0 Then
For VäntLoop = 1 To 1800
If eSignal.IsHistoryReady(HistHandle) Then
NumOfBars = eSignal.GetNumBars(HistHandle)
msgbox NumOfBars
Exit For
End If
Sleep 100
Next
End If
eSignal.ReleaseHistory HistHandle

[Blomman]

Is it really only me having this issue? I have modified the code so that it waits until the number of requested bars is the same as the number of received bars.
The problem is when the number of bars from Esignal's database is less then what I request for. In this case I have to wait for a timeout and just hope that the number of received bars is correct.

Is there any way to roll back to earlier version of Esignal since this happened after upgrade? This problem is creating a lot of extra work for me when I do backtesting.

[scheel]

Yeap, this happens. The example code will get you started, but will not likely work for any type of volume processing.

I don't recommend hanging around for the return from the call. Processing can occur during two events. More on that later.

Here are some code segments that will give you the idea. First, I deploy a throttle mechanism that is adjusted in one of the events. But, suppose you have your securities list and call a proc in the class handler. It gets your list of securities and does the setup for a call to the requestor, proc GetDaily. Here is the loop in that first proc. The oESignal object is a global containing most of my eSignal code. It fires calls to GetDaily; that is where actual eSignal calls occur.

For i = 0 To UBound(SecurityList)
nLatency = 5# * CDbl(oESignal.ActiveSymbolCount)
If nLatency < 10# Then nLatency = 10#
dtWaitUntil = DateAdd("s", nLatency, Now()) '5 is too short. The wait should be a function of the number of items to be received

Do While (oESignal.ActiveHistoryCnt >= 100) Or (oESignal.ActiveSymbolCount >= 100) Or bWait
If Now() > dtWaitUntil Then
nErr = Error.ExceededWaitTimeout
Exit Do
Else
DoEvents
End If
Loop
GetDaily CStr(SecurityList(i)), nDays

'try latency between Requests
If nThrottle <= 0# Then nThrottle = nThrottleDefault 'global could be zeroed by crash
WaitAwhile nThrottle

Next i

Trucking around the next proc will be difficult without all the code. But, the important point is that a collection is used to keep track of what has been requested in RequestHistory and the handle received. ColCookie is that collection, and you'll see below what happens when eSignal.RequestHistory returns something other than trash. I don't do anything serious within the proc that does this call. Rather, I stuff a bunch of info in colCookie collection. I depend entirely on getting something I can use in either event eSignal_OnBarsChanged or event esignal_OnBarsReceived.

'10/3/07 WCS
'Modified to work with generalized timebars
Public Sub GetDaily(sSymbol As String, nDays&)
Dim nCookie&, vC(nCookieItems) As Variant, sInterval$, sIdx$
Dim i&

sInterval = sBarInterval
nActiveHistoryCnt = nActiveHistoryCnt + 1
nActiveSymbolCnt = nActiveSymbolCnt + 1

'Debug.Print "Before RequestHistory", sSymbol

nCookie = eSignal.RequestHistory(sSymbol, sInterval, btBARS, nDays, -1, -1) 'fires event to esignal_OnBarsReceived when data ready


If nCookie = 0 Then

'10/14/07 WCS
'This can occur even when symbol is not invalid. And, the reentry can fail
'with a delay of .5 secs.


'Check validity of symbol.
If Not VerifySymbol(sSymbol) Then
nUErr = nUErr + 1
AddLog sSymbol & " is an invalid symbol"
Else
'what to do? try a couple more times with .5 sec waitstate then trash
For i = 1 To 3
WaitAwhile 0.5
nCookie = eSignal.RequestHistory(sSymbol, sInterval, btBARS, nDays, -1, -1) 'fires event to esignal_OnBarsReceived when data ready
If nCookie <> 0 Then Exit For
Next i
If i > 3 Then
nUErr = nUErr + 1
AddLog sSymbol & " has no data. Cookie=0"
End If
End If
End If

'With eSignal
' Debug.Print "After RequestHistory Cookie=", nCookie, .GetNumBars(nCookie), CBool(.IsHistoryReady(nCookie))
'End With

If nCookie <> 0 Then
vC(colSymbol) = sSymbol
vC(colInterval) = sInterval
vC(colBar_Type) = btDAYS
vC(colNumOfBars) = nDays
vC(colStartTime) = -1
vC(colEndTime) = -1
vC(colHandle) = nCookie
sIdx = CStr(nCookie)
colCookies.Add vC, sIdx
With frmUpdate.lbProcessing
.AddItem sSymbol
.ListIndex = .ListCount - 1 'scroll
End With
Else
AddLog sSymbol & " failed. Could not request history"
DecrementActiveSymbolCnt
DecrementActiveHistoryCnt
End If


'10/12/07 WCS
'Using debug.Print at various points, it appears that
'(1) OnBarsChanged may be fired before return from HistoryRequest
'(2) At least one OnBarsReceived is fired
'(3) Multiple OnBarsChanged are fired

End Sub


In general, what you get in esignal_OnBarsChanged isn't worth much. But, here I check to see if any bars have actually been received...often it is 0(!)). If it's not 0 I pass through a call to OnBarsReceived where I fire off the actual processing. Thoughout all of my code it is colCookies (a global collection) that has all of the flags, handles and other information needed to know what to do.

I have found activity in OnBarsChanged is a good place to regulate my throttle (that is in the first loop above and serves to handle when and how often I call proc GetDaily).

Like you, I have been extremely frustrated with the general operation of the API. The operation of the calls is non-intuitive and in my experience, not what is expected in an event-driven environment. Nevertheless, it is possible to control processing of lists of 1000 or more securities without breaking the bank.

Good luck. Be Happy.

[Blomman]

Thanks a lot for your reply. It gave me a lot of ideas how to do the code in a different part of my program

The problem is that I want to receive all the requested historical data before I do the processing. Since IsHistoryReady is useless after the upgrade, it seems impossible to know when all the data is received.
However, I have now solved it by checking the number of received bars and if it doesn't change within a certain time I assume that all data is received.
Of course if the number of received bars is the same as the requested, I will also do the processing.