Posted: Oct 21, 2011 @ 03:47 PM             Msg. 1 of 3

Hi,

We have a function that tries to see if a symbols subscribed doing the following:


ISubscriptionListPtr subs = OECAPI()->GetSubscriptions;
for(int i=0; i< subs->Count; i++) {
ISubscriptionPtr sub = subs->GetByIndex(i);
if(sub->Type == SubscriiptionType_Bar && sub->Updatable) {
// compare symbols, interval, and sub->Start seconds
// Note if the one we are looking for is found.
}
}


We have noticed that if this code is called before the subscription list is stable, GetByIndex will raise an exception and return null.

Why would we not be able to GetByIndex for an index within the range of Count?

Would we have better luck iterating the list in another manner?

Is there some "subscription list complete" message we've been overlooking that we could pend these lookups on?

We often run into issues with subscriptions after connecting or reconnecting so something about how we handle it seems to not be in sync with the way it was designed to be handled. We would appreciate some insight to help us make this more robust.

Thank you,
Jacob

Posted: Oct 25, 2011 @ 10:12 AM             Msg. 2 of 3

Hello,

your code snippet is perfect for iterating.

The list can be considered as a stable one, if all operations are performed in context of the thread that created OECAPI instance.

We tried to reproduce this issue without success. Could you please provide more details how to reproduce it?

---

Victor Vins
Lead Software Developer

Posted: Jun 13, 2012 @ 01:21 PM             Msg. 3 of 3

I apologize for not replying earlier to this. We do touch the API from two other threads when we load a chart to look at properties on a contract, like market hours, or to start a history request so I couldn't say that wasn't the reason for the error.

I ran across this again, and this time I went to lengths to disable or temporarily rework those calls so they are all within the thread that creates the API instance (the main windows thread) and still I had the problem. It showed up readily when I switched from using subs->Count in the loop test to a const variable that grabbed that value before the loop.

The problem in this new case, and perhaps in my initial report I forget the context, was that I was calling Unsubscribe as I looped over the list. Similar to deleting an item from a container in an unsafe way while iterating over it. I avoided that issue by instead building up a list of symbols to delete, then iterating over that list to reacquire the contract pointer and unsubscribe from it.