We Need Your Questions & Suggestions

[JayF]

Good news. We've just been given a developer to work entirely on ActiveX for the next 2-3 weeks; answering questions, and creating enhancments to be included in the next version of eSignal. What we are looking from any Desktop API users is... What questions do you need addressed? What features do you need the most?

Here's a breakdown of what we currently have scheduled for the developer.

- Investigate GetTimeSalesBar() and fix com exception on Win2k.
- Add GetTimeSalesDataArray() and IsTimeSalesHistoryReady().
- Enhance "Quote Stream" to include size information for $PLAYBACK
- Fix premature OnBarsReceived event.
- Investigate Start/End Time in historical requests; fix/enhance if possible.
- Add CloseAllRequestHandles()
- Investigate adding "absolute indexing" of ticks and bars

[GenSpoo]

Hip hip hurray!

I am still interested in the possibility of Globex/ECBOT/Eurex depth of market via the API. But other that that, looks good to me.

And, BTW, you could hire me to be a permanent full time API developer for you. I wouldn't mind.

[bullman]

That’s a good start. There are many more issues that prevent eSignal from being a viable platform for third party development. I am actively developing an application that is currently using the eSignal API. Read below – I am at my wit’s end. I would be happy for you or the developer to contact me or use me as a beta tester.

You asked, so here goes….

1. Many times when I call RequestHistory () for a particular symbol, no data is returned. While my program is in the process of waiting, if I go to the eSignal File menu and select New / Advanced Chart, and change the symbol and interval in the chart to what I am waiting for, instantly the data is also returned to my program as well. So to free up a “stuck” symbol in my app, I am constantly manually entering it into a chart in eSignal. I do not know what causes a symbol to be stuck, but once it gets stuck, it will remain stuck and inaccessible to the API until I manually enter it into a chart in eSignal (apparently, the API thinks it has requested data for the symbol from the servers, but has not. When I create a chart for the symbol, eSignal makes a request for the data, and the API grabs this data also and returns it to the app).

2. It takes eSignal 8 – 10 minutes (yes, minutes) to return data when I make a call to RequestHistory () for approximately 2 months worth of intraday data. This sounds more like a prioritization issue with the eSignal servers than the API interface, but it needs to be addressed.

3. If I request 1000 bars of data with RequestHistory (), why do I need to make 1000 calls to GetBar () to retrieve that data? It is slow and processor intensive. Why not one call to a function called GetBars (n, buff) that fills “buff” with “n” bars. (I think you mentioned something like this in your list for GetTimeSalesDataArray () – it needs to be implemented for RequestHistory () also).

4. The <start_time> and <end_time> for RequestHistory () is very important so I can calculate the maximum number of bars per day (e.g., 390 one minute bars) and request that number of bars times the number of days I need. With it not working, I have to request significantly more bars than I think I need because I have no way to cap the number of bars per day - stocks that are heavily traded after hours (MSFT, AMAT, etc.) generate significantly more bars after hours that I have to overcompensate for. It slows down my app and unnecessarily loads your servers.

5. After requesting and receiving historical data for a symbol, I promptly call ReleaseHistory (). That symbol should no longer be counted toward my symbol max of 500. But after requesting and releasing the handle for the 500th symbol for the day, I get warning messages popping up that I have exceeded my symbol count. If I go to the Data menu of the eSignal data manager and select Symbols, it shows these symbols as active, even though I have released them.

6. Does the API support multiple apps running at the same time or not? I need a clear statement on this for my design, even if the answer is no.

7. If I RequestHistory () for a bad symbol (or a symbol that has recently changed), eSignal returns a valid handle, but does not generate any ES_OnBarsReceived, ES_OnBarsChanged, or any other messages, leaving me hanging. How can I determine if a symbol is invalid, other than just timing out after a long wait for data (not practical). I need some message or error code that lets me know the symbol is not valid.

I could come up with additional with a little more thought…

[Mark Rockley]

Differing numbers of bars

With a request history of a fixed number of bars (daily bars), the number of bars returned varies from stock to stock, usually by just 1 bar. So IBM might return the requested 25 bars, but AMD might return just 24 bars and this happens reproducibly with the same two stocks.

[Mark Rockley]

Symbol release

After requesting and receiving historical data for a symbol, I promptly call ReleaseHistory (). That symbol should no longer be counted toward my symbol max of 500. But after requesting and releasing the handle for the 500th symbol for the day, I get warning messages popping up that I have exceeded my symbol count. If I go to the Data menu of the eSignal data manager and select Symbols, it shows these symbols as active, even though I have released them.

I have verified this difficulty in my own work. It severely restricts the utility of the API.

Does anyone know a fix for this failure to release the symbol?

[Mark Rockley]

One big need is documentation

I think a lot of the questions folks are having with the API would go away if there were functional examples of each hook, function, flag etc. in the various languages e.g. Basic and C.

You know that the example and documentation is good enough when it supports a cut and paste approach with a small amount of knowledge.

It might be useful to have a full blow app. with menu selections which illustrate each function so that the end user can get a sense of the syntax. Hacking through hoping that one makes the right calls etc. is really challenging.

[Table32]

When your developer has done all the fixing etc, will you be making the new API available to download or are we going to have to wait for 7.6 to be released?

Cheers,

T32.

[JayF]

.

Originally posted by Table32
When your developer has done all the fixing etc, will you be making the new API available to download or are we going to have to wait for 7.6 to be released?

My understanding is that ActiveX fixes and features will need to be rolled out with 7.6. If we go on what we've seen in the past, 7.6 will have 4-6 weeks of beta testing, and it's likely that these features will be included at some point during the beta cycle. I haven't heard of a date yet for the start of the beta, but I've heard that it should happen soon (my guess is within a few weeks.)

[JayF]

FYI, regarding the other questions in this thread, we haven't forgotten about them... we are just working on responding to them.

[JayF]

Here's a post from the developer that has been working on ActiveX, and answering questions for us.

=======

I thought I'd just let you guys know what fixes have been done before the New Year, and also answer some of the questions in this thread.

- IsTimeSalesHistoryReady(). -- Finished. Will be in 7.6.
- CloseAllRequestHandles() -- Finished. Will be in 7.6.
- Fix premature OnBarsReceived event. -- Fixed. Will be in 7.6.
- Investigate adding "absolute indexing" of ticks and bars -- Finished. Will be in 7.6. (though the absolute indexes can still change if the back-loading of historical chunks of data is still in progress [IE IsHistoryReady still returns FALSE])

"1. Many times when I call RequestHistory () for a particular symbol, no data is returned."

This may be fixed with the "premature OnBarsReceived" above.

"2. It takes eSignal 8 – 10 minutes (yes, minutes) to return data when I make a call to RequestHistory () for approximately 2 months worth of intraday data."

I made a change in 7.6 that should improve the performance of requesting large amounts of intraday data. eSignal can process 10,000 intraday records in ~20 seconds on my 1GHz now. (this is before the API client starts getting bars, though, that will only be improved once the GetBulkBars or whatnot is added). I am also thinking about other improvements in this area.

"4. The <start_time> and <end_time> for RequestHistory () is very important so I can calculate the maximum..."

I'm not quite sure I understand the problem here -- days can have
varying number of bars, depending on how much the instrument has traded. If you want at least the last 15 days of any stock, you should be able to set the start time to 15 days ago and do the request, rather than mess around with the average/maximum bar count? You may get more data than you requested, but you should end up with the complete set of data, and then you can toss what you don't need?

"5. After requesting and receiving historical data for a symbol, I
promptly call ReleaseHistory ()..."

The DM caches symbols. These can be cleared by doubleclicking the "Sym xxx" box in the bottom right of the status bar (to the left of the two [hopefully] green OKs). This might be useful as an API function as well...

"6 Does the API support multiple apps running at the same time or not? I need a clear statement on this for my design, even if the answer is no."

Yes and no. Both applications will get all events for both
applications, but if you structure your applications to ignore events for handles/symbols it is not concerned with, it should work fine.

Cheers and happy holidays,

Simon.

[GenSpoo]

Thanks Simon. Sounds like excellent progress.

With regards to the <starttime> and <endtime> with intraday request history, my issue is that I watch globex futures and sometimes just want to see bars from 9:30 to 16:15. It is my understanding from the documentation that I could set the starttime so as my app would receive none of the premarket data. That doesn't seem to happen for me (last time I tried it). I get the full 24 hours even if I ask for just RTH. I have a hack in my app to filter out to bars manually, but it would be nice if the API filtered for me so my GetBar loop didn't have to know about time. And, even more importantly, when the GetBulkBars function is implemented, it will ideally know about <starttime> and <endtime>. Hope that all made sense.

Having the clear cache as an API would be good IMHO since the whole point of the API is to be able to work from outside the main client app.

Cheers... George

[Objectivist]

Sounds like great progress.

Does the "absolute indexing" change you've made allow the index numbers of historical ticks to remain the same during market hours (as new realtime ticks arrive)? If so, that would probably address most of my complaints with the ActiveX API.


What about the com exceptions that I occasionally get when making calls to GetGetTimesSalesBars(), as discussed in:

http://forum.esignal.com/showthread.php?s=&threadid=5712

and:

http://forum.esignal.com/showthread.php?s=&threadid=5816

These were mentioned in an earlier post regarding the problems you intended to address.

[bullman]

Excellent. Thanks for your speedy work and replies. When will the beta 7.6 be available?

To clarify <start_time> and <end_time>, it is strictly an intraday filter. If I do not want pre and post session data for stocks, I should be able to set this to 9:30am and 4:00pm to get data only during market hours. it does not have anything to do with how many days of data you are requesting.

Regarding ReleaseHistory (), we have a 500 symbol max, after which the data manager will scream at us. When I ReleaseHistory (), I am done with the symbol and it should no longer count toward the 500 max. If we need to clear the symbol from cache to have it no longer count, then PLEASE include a ClearSymbol () function in the API.

Regarding RequestHistory and having no data returned, I am convinced there is a bug in the API. From my experience, about 10% of the symbols I request get "stuck" and are never returned, unless I open a chart window in eSignal for the exact symbol and interval requested, in which case the symbol is "freed" and data promptly sent to my app. Closing and restarting my app and/or eSignal does not even seem to release a "stuck" symbol.

[sthornington]

re: <start time> and <end time>

The reason this doesn't work as you would expect is that these are just parameters we send to the servers to give us data. The server is allowed to (and does, for reasons of its own) send more data than we ask. As a consequence, you have access to all the data eSignal does, which is often more than you strictly requested. In a GetBulkBars method, it would be as easy for us as for you to filter out the bars undesired. In a GetBar method, done by index, where we're just indexing into the complete set of data we have, there's no record of what was originally requested.

re: absolute indexing

Yes, after the backfills of historical data are done, the index base should remain constant. I added another event which should fire if the base changes (by a backfill), but I haven't had time to do extensive testing of this though.

re: COM exceptions

I haven't had time to build a win2000 box to try and replicate this, sorry.

Cheers,

Simon.

[Objectivist]

I get the com exceptions under Windows XP.