lifetime of timeandsalesbar

[cgaylord]

Looking for concept, but actual details would be great.
Esignal 7.7(Build 646)
VB.Net 2003

What happens to the TimeAndSalesBar after a few days/weeks/months (if one manages to have uninterrupted operation)?

We have a very basic app that attempts to build a database of raw tick data for just a few contracts. We start collecting the real time data as soon as it triggers and add the days of history (as needed) when it becomes available -- this in order to be able to fill data if/when the computer/apps are shut down for awhile and brought back up. We query our own database at the start up to find out how many days we might be missing since the end of the last collection.

We have relied heavily on a "quickie" app recently posted by George.

Here's where I may be wrong. It appears that when one does a

tshandle =esignal.RequestTimeSales(filter)

one is actually asking the esignal DesktopAPI to start building a bar set of raw time and sales data. And, then, once having asked the API to start building this bar set, one can retrieve data from it and are notified via "OnTimeSalesChanged" when the bar set has changed.

The number of bars in the set seem to continually increase. If one has requested history they are included in the bar set. One can determin how many arrived via history and real time because one can request both GetNumTimeSalesRtBars(tsHandle) and GetNumTimeSalesBars(tsHandle).

But the bars keep building. What happens after days/weeks/months?

Should one be resetting this somehow and, if so, is there a way not to miss transactions that happen during that process?

Thanks for any insights.

[Guest]

Hopefully other developers will chime in, as they have a better understanding of the nuances of the API. I will add what I know:

There are currently 10 days of T&S data available via the API. (We have some servers with 30 days of T&S data, but it is not in production yet.)

Time and Sales data cannot be filtered intra-day, meaning all T&S for the days in the filter will be returned by the server(s). The filter is in eSignal and the same class was used for the API, which explains the confusion in the documentation.

I would recommend a "clean up" process each day, maybe releasing the handle and getting a new one, while also performing some programmatic QA on your database - to make sure the data looks good. You could create batches of requests for each day and if the connection was lost when you were away, you could easily backfill the missing info.

I hope that helps.

[cgaylord]

maybe problem releasing handles

Actually, we maybe having a problem releasing handles.

We have tried both

esignal.ReleaseTimeSales(tsHandle)

and

esignal.ReleaseAllTimeSales()

But, still, each time we restart the app it uses the next handle number after the last one we used. Maybe this is by design and the handles are actually released.

We can close and reopen our app and still the same. We can close and reopen esignal as well, and still the same.

The only way we've discovered for the handles to start over again at 1 is to reboot the system.

What do you think?

[Guest]

The consecutive numbering is by design.

You can call ClearSymbolCache() to remove the symbols in the DM (Data -> Symbols). The Data Manager is what manages the symbols in both eSignal and anything via the API. That function should be a part of the "clean-up process" I mentioned.

That should start the sequence over, but don't hold me to that.

[LTANESIGNAL]

Robi can you confirm that the callback handles given by the API would be consecutive, BUT ClearSymbolCache() would reset it to 1? Can this be made an official part of the API or at least mentioned be made if this behaviour is changed?

I'm asking because this would save me the trouble of implementing a handle to symbol lookup.

[Guest]

ClearSymbolCache() does not necessarily reset the handles to 1. It clears the list of symbols stored in your Data Manager.

Handles are randomly generated by the COM object and should not be considered indexes to symbols because handles are not only related to symbols. There are many other non-symbol related events that use handles to communicated between eSignal and your application. It would be in your interest to use a handle/symbol lookup function.

[cgaylord]

just a comment on this

It's been our experience that the Desktop API doesn't actually "randomly" generate handles - tho it may. It seems to always use the next available handle. That is, whatever handle was used last + 1. We have not tested this adequately to be definitive.

We've tried several things as well to reset these handles so we avoid the tracking of handles to symbols, but without success. Actually, it should be possible to make a relative tracking for arrays or such so that it's the handle minus the first handle assigned since they do seem to always be consequtive since the last used handle. However!, that seems to risky and the overhead for tracking what handle is associated with what symbol is minmal.

In vb.net we use a hashtable to track this and that seems to be fine. No risk that way.

The ONLY way we've discovered of resetting the the handles is by rebooting the machine. Simply closing the third party app and the eignal app and datamanager does not do it.

Not sure what is cleared when one reboots, but if one does, then the handles start back at the beginning. Anything short of that seems to keep them incrementing.

Just a fairly worthless observation. Robi's comment is the best. It seems one really needs to keep track of the association.

[LTANESIGNAL]

Thanks Robi, cgaylord

for those interested the following thread provides the information I was looking for
(http://forum.esignalcentral.com/show...threadid=5619.

I ended up maintaining my own association using a multidimensional array (making the assumption that the handles are handed out in the manner described above).