Tweet
Timesales Request
Does someone have a way of handling realtime and historic timesales bars correctly? in the c++ samples i've only seen realtime bars handled, but how about realtime and historic at the same time? any help appreciated. Any explaination of how ontimesales works in blocks, the correct way of handling both types of bars, etc... thanks
-
-
Hi twiz,
I think there is a sample in the ActiveX Fileshare that may be what you're looking for. It is incorrectly named "Multiple History Requests in VB.zip" but it's actually a C# sample. -
timesales - please help
Hi Starr,
Thanks for your help. I've got timesales data working correctly now in OnTimeSalesChanged event in C++ VS 6.0 with eSignal 8.0
I have noticed sometimes the data comes in differently. I think this maybe an internal bug in esignal 8.0. I'm not sure if i'm doing something wrong. But I simply use GetRequestTimeSales with the filter and wait for the OnTimeSalesChanged event to handle the request.
In OnTimeSalesChanged I wait until TimeSales is ready (GetIsTimeSalesReady) then proceed and get all the bars. Is this the right thing to do? or should I process the bars for each event fired. I don't think it really matters?
I'm trying to get 10 days. 3 days or less works fine everytime, but when I go more than that ie. max 10 days, the data is different sometimes, its like eSignal is skipping some bids/asks and the trades have same price but different times. I even trying killing winsig and winros and running up the app again. The number of history bars changes! why? I've compared the data many times and its just unrealiable - Do you know why this is happening? I am going crazy trying to find out what it is? I'm thinking a memory problem or something in winsig?
Hope you can help! I can't sleep until this is resolved. Thanks.
Regards,
Twiz
Comment
-
Instead of using GetIsTimeSalesReady, can you try processing the bars when esignal_OnTimeSalesChanged is triggered?Comment
-
Hi Anthony,
I do process the bars in ES_OnTimeSalesChanged function when its triggered. In that function I only read bars if timesales is ready (so its in the cache??) with GetIsTimeSalesReady, if not ready the function just returns. So when ready I proceed and read all history bars (GetGetTimeSalesBar)...as ES will fire another event when ready. And that seems to be the problem how the bars times differ and bid/ask are skipped from time to time. Is there a cache problem here? I originally thought cache wasn't used for realtime data.
Yes I have tried without GetIsTimeSalesReady and process the block of bars (GetGetTimeSalesBar) as they come in, this also produces the same results.
So I would have to say a bug in esignal 8.0? You try requesting timesales for say 10 days, do it repeatedly and you will see the data becomes different, especially if you kill winsig/winros and reload you get a different history bars count and some bars are missing. Do you know whats causing this? How can I fix this?
Regards,
TwizComment
-
From your post below, are you requesting 10 days of tick data from the Desktop API or are you actually requesting 10 days of tick data from the eSignal application directly? Do you see this issue when requesting less than 10 days of data?
What symbol are you requesting tick data for?
Without restarting your eSignal application, datamanager or your application, if you make 3 separate request for 10 days of t&s data. How many ticks do you get back each time?
We will investigate this issue furtherComment
-
One thing would suggest is waiting for a minute to pass with no changes in the count before collecting the bars. Because of the way bars are fetched and the absence of an API call to determine when all the bars are in I've found this is needed to stabilize the dataset.
The request for a call for this as well as one to return an array of data was made at least three years ago. I don't know if eSignal has done either since those requests.
-JimComment
Comment