Posted: Mar 30, 2016 @ 04:41 PM             Msg. 1 of 9

I am a developer for the Trade Navigator software which connects to Gain through the C# API. I have found that under regional settings in which the comma and decimal point are reversed ( like several European countries ) when we place the first order for the day for a particular symbol ( Natural Gas and Heating Oil have been the symbols that have run into the issue ), the order price will come back without the decimal point in it and then the order gets rejected. Because it is the first order of the day for that symbol, I place the order in a waiting queue and then call OecClient.SymbolLookup on the order. Once I get the corresponding OnSymbolLookupReceived event, I then submit the order. When I go to submit the order, I called OecClient.CreateDraft sending in the following string: DEMO062138;Buy;1;GHOK6;Limit;None;1.1618;0. After the CreateDraft call, the order draft looks like the following: Account=DEMO062138, Comments=, Symbol=GHOK6, End=99981231-00:00:00, ExecInst=None, ExtData='(null)', Flags=None, PIN='(null)', Price=11618, Price2=0, Quantity=1, Route='(null)', Start=17530101-00:00:00, TradingSession=Unspecified, Type=Limit. Note that the price does not have any decimal points in it. Keep in mind, I am doing this using regional settings such that the decimal separator is a comma and the thousands separator is a decimal point ( if that information matters ). Any subsequent calls to CreateDraft for that symbol succeed.

I have verified that everything works fine under US settings and I have verified that I am doing any conversions between strings and doubles with the System.Globalization.CultureInfo.InvariantCulture flag. This is a weird one for sure because it only seems to happen for that first order of the day for the symbol.

Any help would be greatly appreciated.

Posted: Apr 04, 2016 @ 03:25 PM             Msg. 2 of 9

Hi David,

Yes, that problem seems very odd at first glance. I reviewed the CreateDraft() method, and here is what I see.

If your client does not have the given contract within your OECClient Contracts, the current culture is used to parse the string. Since your current culture uses '.' as a divider, it is ignored during the parse, resulting in Price=11618.

Later, you call the same function. This time, though, the contract is within the Contracts list. CreateDraft() now utilizes a more advanced parsing method that incorporates the current culture and contract information to generate the correct string.

Since you are calling these methods right after OnSymbolLookupReceived fires, the corresponding contract might not have had enough time to populate into OECClient Contracts. If that doesn't work, you will need to look at your threading and synchronization. Hopefully this solves your issue.

Posted: Apr 05, 2016 @ 01:21 PM             Msg. 3 of 9

Thank you for your response. What you said is pretty much what I assumed. However, I can tell you that after I get the OnSymbolLookupReceived event and walk through the list of orders that are waiting for symbols, I am ensuring that the base contract exists using _oecClient.BaseContracts.FindBySymbol and then verifying that the contract exists in the Contracts collection of the base contract that I get back from the call. So I can tell you that those collections have been updated. What I don't know is if the CreateDraft function is checking something else.

Posted: Apr 06, 2016 @ 01:10 PM             Msg. 4 of 9

Can you verify the contract is in your oecClient.Contracts collection before you call CreateDraft()?

Posted: Apr 14, 2016 @ 11:25 AM             Msg. 5 of 9

I reworked the code to wait until the symbol existed in the oecClient.Contracts collection, but the customer is still having the same issue.

Posted: Apr 15, 2016 @ 03:36 PM             Msg. 6 of 9

Does this string change at all between the first call and the working calls to CreateDraft?

DEMO062138;Buy;1;GHOK6;Limit;None;1.1618;0

Which regional settings or CurrentCulture are you working with?

Posted: Apr 18, 2016 @ 11:00 AM             Msg. 7 of 9

Obviously, the string will change as appropriate ( different prices, different order type, etc. ), but the decimal point in the price doesn't change ( it is always formatted the same ).

The customer who is running into the issue is in Luxemburg, so I am assuming that is the culture he is using.

Posted: Apr 19, 2016 @ 10:19 AM             Msg. 8 of 9

I'm sorry David, I don't see anything else that could change behavior. When you pass the template string into CreateDraft(), it breaks up the string and handles each element separately. For the price parser, only two inputs are sent: the contract (which is grabbed from OECClient.Contracts["contract string"]) and the price string. The parser will not change its behavior if it gets these same two inputs unless there is also a change to CultureInfo.CurrentCulture. This is not changing, is it? If not, are you performing these actions on a separate thread from the one that created your OECClient?

Posted: Apr 26, 2016 @ 04:59 PM             Msg. 9 of 9

I did find out that when an Elapsed event of the System.Timer occurs, it is on a different thread. That thread by default seems to have some default culture set. What I ended up doing in that Elapsed event is setting the CultureInfo.CurrentCulture to an invariant culture ( which uses US settings ) and that seemed to work for the client.