Initial OnTimeSalesChanged events

[mabon]

I'm relatively new to the eSignal desktop API but I haven't seen this problem covered in the documents on the file sharing page nor in this forum.

I've built a test app which displays time and sales, and in order to get the most current Bid and Ask I subscribe not only to T&S events but also to quote events. When I start the app I make a single call to RequestSymbol for my quote events, and a single call to RequestTimeSales supplying my filter. Today I'm testing without the markets being open, and for quote events, I get one or two stale events printing in my listview which is no big deal, but for T&S events, I check get_IsTimeSalesReady and find it to be false ( even after sleeps of over 10 seconds ), and I then get a chain of exactly 255 OnTimeSalesChanged events for my correct handle even though the return from get_GetNumTimeSalesRtBars is always zero. Always exactly 255 events with the same T&S bar repeating over and over which I'm guessing was the last bar recorded prior to market close.

I have tried clearing the symbol cache, releasing all symbols, releasing all history, and releasing all time sales but nothing seems to clean out this stale data. I've even tried killing data manager and resetting the databases but no joy.

Does anyone have any idea where this data is coming from and why I can't get rid of it?

Thanks for your help,

- Richard

[Guest]

This has not been reported before and is very strange. It makes sense that it is the last price, but I am not sure I know where it is coming from.

Are you sure nothing is being stored in your application that could account for this? Does this only occur when the markets are closed? Which symbols?

[mabon]

I have a little more information from trying to debug this problem.
No, I am not saving these bars in my app just displaying them as the events are received.

These events are apparently not sent when the markets are in session because then I get a single event indicating there are X number of waiting RT bars ( which are legitimate realtime bars in the queue) which I display when I first request time and sales. But when the market is closed, these events are first processed then the app seems to wait appropriately for legitimate new events even though there are none. But if I call ReleaseAllTimeSales and ask for time and sales again, then I get the events again. The other thing I noticed was that the return from IsTimeSalesReady continues to be false until all these events have been sent and processed. After event 255, it becomes true, but if I put sleeps in my event handler, IsTimeSalesReady will not return true until event 255 is processed.

The problem of printing bars that I don't want is obviously avoided by the logic in my loop since I look for GetNumTimeSalesRtBars to be >0, (and in this case GetNumTimeSalesRtBars returns zero), I just didn't like the idea of getting all these bogus events for duplicate bars. It seemed to me to possibly be a bug in the way the cache is being initialized.

From what I can tell it appears that eSignal is caching multiple copies of the last bar thinking that these were the last realtime bars but for some reason setting the return from GetNumTimeSalesRtBars to 0. Since my filter is set to 1 day, I'm not surprised that I'm not getting the last bars from the prior session, I just expected not to have to process any events when I requested time and sales after the market was closed, even events where GetNumTimeSalesRbBars was zero.

[GenSpoo]

Are you still having problems with this? I'm a little confused as to what exactly the problem is. It might help if you have a sample application you could post for us to look at?

Originally posted by mabon
The other thing I noticed was that the return from IsTimeSalesReady continues to be false until all these events have been sent and processed.

I believe you are describing the correct behaviour of the function. IsTimeSalesReady is meant to only return true when all of the historical time and sales have loaded.

Cheers... George