| API Support » Possible Regional Settings Issue with OECClient.CreateDraft call Apr 26, 2016 @ 04:59 PM (Total replies: 8) | |||||
|
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. David Jarmuth
|
|||||
| API Support » Possible Regional Settings Issue with OECClient.CreateDraft call Apr 18, 2016 @ 11:00 AM (Total replies: 8) | |||||
|
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. David Jarmuth
|
|||||
| API Support » Possible Regional Settings Issue with OECClient.CreateDraft call Apr 14, 2016 @ 11:25 AM (Total replies: 8) | |||||
|
I reworked the code to wait until the symbol existed in the oecClient.Contracts collection, but the customer is still having the same issue. David Jarmuth
|
|||||
| API Support » Possible Regional Settings Issue with OECClient.CreateDraft call Apr 05, 2016 @ 01:21 PM (Total replies: 8) | |||||
|
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. David Jarmuth
|
|||||
| API Support » Possible Regional Settings Issue with OECClient.CreateDraft call Mar 30, 2016 @ 04:41 PM (Total replies: 8) | |||||
|
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. David Jarmuth
|
|||||
| API Support » Forex Historical Data Nov 06, 2013 @ 11:54 AM (Total replies: 3) | |||||
|
When we subscribe to data, we are using the "Subscribe" method. Should we be using the "SubscribeTicks" instead? David Jarmuth |
|||||
| API Support » Forex Historical Data Nov 06, 2013 @ 11:30 AM (Total replies: 3) | |||||
|
We have been collecting the Forex data here and accumulating data to put out to our customers. I have been trying to download history through the API to supply some history. However, when I compare the data I receive from history, it is not matching the data we are collecting exactly. When we collect data we are using the LastPrice and LastVol as the tick price and tick volume. We are also assuming a 1700 Eastern to 1659 Eastern session. When I download history, I am using the following call: RequestBars(_symbol, _startTime, _endTime, OEC.Data.SubscriptionType.Bar, 1440, false); I have also tried without specifying the "IgnoreSessionBoundaries" argument. Any insights as to why the data doesn't match? I have tried all three sites ( api, sim, and live ) and have been told that I should only use the live, but even that doesn't match exactly. Thanks in advance for your help. David Jarmuth |
|||||
| API Support » Standard versus Mini FX Accounts Oct 11, 2013 @ 12:16 PM (Total replies: 4) | |||||
|
Thank you. That is quite helpful. David Jarmuth |
|||||
| API Support » Standard versus Mini FX Accounts Oct 11, 2013 @ 10:42 AM (Total replies: 4) | |||||
|
That is kind of what I thought. However, does that mean that I won't know the contract size for sure until the user is in a position? David Jarmuth |
|||||
| API Support » Standard versus Mini FX Accounts Oct 11, 2013 @ 09:51 AM (Total replies: 4) | |||||
|
Can I use the account type on an account to assume what the contract size is for a forex? For example, if the account type is "Standard FX", is the contract size always going to be 100000 and is the "Mini FX" always going to be 10000? Or, do I have to read the contract size coming back on a position ( which is really a little too late )? David Jarmuth |
|||||