c++ GetRequestTimeSales Overloading winsig

[giaru1]

I have some code that can successfully get the time/sales data for a few stocks. I am trying to use time/sales to get 1 day of data for 500 stocks plus get real-time updates.

The following code fragment works with 5 stocks, but with 500 it has two errors: 1) it doesn't get more data, and 2) I get a message box saying winsig cannot communicate with my application, and asks me to retry or switch-to.

Here is the code fragments:

for (l=0; l<490; l++) {
AxNext();
}

void CMainDlg::AxNext()
{

if (ax_symbol_list.IsEmpty()) return;
ax_symbol = ax_symbol_list.GetHead();
ax_symbol_list.RemoveHead();


TimeSalesFilter f;
f.sSymbol = S2B(ax_symbol);
f.bQuotes = TRUE;
f.bTrades = TRUE;
f.lNumDays = 1;
f.bFilterPrice = FALSE;
f.bFilterVolume = FALSE;
f.bFilterQuoteExchanges = FALSE;
f.bFilterTradeExchanges = FALSE;
f.dMaxPrice = 0;
f.dMinPrice = 0;
f.lVolume = 0;
f.sQuoteExchangesList = S2B(" ");
f.sTradeExchangesList = S2B(" ");
m_hHistory2 = (*m_piHooks)->GetRequestTimeSales(&f);
ASSERT(m_hHistory2<4096);
ax_handle_symbol[m_hHistory2]=ax_symbol;
ax_handle_cnt[m_hHistory2]=0;
printf("new handle %d %s",m_hHistory2,ax_symbol);
ASSERT(m_hHistory2);



}


void CNdxDlg::ES_OnTimeSalesChanged(long l) {
long lNumBars;
long lNumRtBars;
TimeSalesData baritem;

lNumBars = 0;
lNumRtBars = (*m_piHooks)->GetGetNumTimeSalesRtBars(l);
lNumBars = (*m_piHooks)->GetGetNumTimeSalesBars(l);
if (lNumBars==0 || lNumBars>ax_handle_cnt[l]) {
ax_handle_cnt[l]=lNumBars;
return;
}
int date,sec;
int first_date=0,first_time=0,last_date=0,last_time=0;
baritem = (TimeSalesData)((*m_piHooks)->GetGetTimeSalesBar(l, -(lNumBars-1)));
ConvertTime(baritem.dtTime,date,sec);
first_date=date;
first_time=sec; //seconds since midnight
if (sec>9*3600+32*60) {
return;
}
SYSTEMTIME dt;
GetLocalTime(&dt);
for (long i = -(lNumBars-1); i <= 0; i++) {
baritem = (TimeSalesData)((*m_piHooks)->GetGetTimeSalesBar(l, i));
ConvertTime(baritem.dtTime,date,sec);
last_date=date;
last_time=sec;
}
printf("%d:%d:%d.%d %s read %d bars %d-%d %d:%d:%d to %d-%d %d:%d:%d",
dt.wHour,dt.wMinute,dt.wSecond,dt.wMilliseconds,ax _handle_symbol[l].GetBuffer(0),
lNumBars,
first_date/32%16,first_date%32,first_time/3600,first_time/60%60,first_time%60,
last_date/32%16,last_date%32,last_time/3600,last_time/60%60,last_time%60);
(*m_piHooks)->ReleaseTimeSales(l);
if (ax_handle_symbol[l].GetLength()==0) {
int iii=0;
}


}

[giaru1]

What I now understand about RequestTimeSales

I seem to have gotten request time/sales to work reasonably well, and I now understand more than I did when I read the original documentation. Not everything is clean yet, so some of what I am writing may be inaccurate. Correct me if so...

When you open up a handle to RequestTimeSales winsig (esignal desktop) gets all historical price and bid/ask bars from the home office, and begins to log new ones. These are kept stored in winsig. Historical bars are all events that occured before the handle was created, and 'real time' bars are all events thereafter.

I got confused initially, because I could not understand what 'real time' bars were. It seemed that all new price information should be sent through continuous quotes. In fact real-time bars are redundant with quotes, and you might ask for both. RT bars have an advantage for me, because they also include the time of the transaction, so I don't have to worry about network latency.

A signal is sent to our applications whenever there are new RT bars, whenever about 1000 historical bars have been added, and whenever all the historical bars are in. Historical bars are loaded from most recent to oldest. We can randomly access those bars by number, with negative numbers being historical, and positive ones being real time.

If you are downloading bars as they come in, and keeping them in your own data structures, you keep track of which ones have already been loaded.

For example, bars -1000 to zero might come in first, then you could get -2000 to -1000 along with realtime bars zero and one. Then -3000 to -2000 and RT bar two, etc.

In the C++ example code the event sink is attached to the main window. I have not experimented with other configurations. In this case the event sink is in the main thread.

If you are doing a lot of processing, or even just reading a lot of new bars, there will be too much time elapsed between visits to the message loop to accept the signals from winros/ActiveX. There will be an error message that your application is not responding, and everything will hang up. Even if you restart everything nothing quite works again.

My solution is to put all processing into a separate thread. One problem with this is that the user interface/graphics really needs to be in the foreground thread as well, and a lot of my graphics are pretty intensive. So what I am doing is breaking my application in two, one process runs the user interface, the other does the tick collection and processing. There is socket communications between them. I had already done most of this work anyway, so that I could have my application run across several computers if I wanted to track a large amount of stocks.

It does appear that Winsig holds all of the tick data even if you close your application.

I also had some problems asking for too many handles too quickly. This may be a bug I have, I don't know. I worked around it by asking for 20 handles, and then only asking for another when a previous one had completed its history download.

Of course I keep all the handles open until the end of the day, so that I can accept new bars.