API Support Forum
User Profile

Viewing User Profile for: WWatson2582


May 03, 2018 04:49 PM

Feb 24, 2021 09:37 AM

Apr 05, 2021 11:20 AM

Post Statistics
WWatson2582 has contributed to 34 posts out of 5095 total posts (0.67%) in 1080 days (0.00 posts per day).

20 most recent posts:

API Support » GAIN API COM uuid change? Feb 24, 2021 @ 09:37 AM (Total replies: 2)

Thanks, Chris!

API Support » GAIN API COM uuid change? Feb 24, 2021 @ 09:15 AM (Total replies: 2)

Will the UUID we were issued for the older OEC API still work with all GAIN servers for the GAIN API COM? We have one beta tester who is trading on the live server and everything is working and a different user that reports that when he tries to connect, he gets a connection failure message with the reason "User software is not allowed to connect." Not sure what to tell them about this. We seem to have everything working now and should have our conformance spreadsheet to you in a matter of days.

API Support » OSO orders bug in COM API Feb 24, 2021 @ 09:10 AM (Total replies: 12)

We're working now fine, so you can consider this issue closed. Thanks!

API Support » OSO orders bug in COM API Feb 19, 2021 @ 09:50 AM (Total replies: 12)

I'm not sure I understand why reporting non-existent orders to the client is a "feature", but I have worked around this by filtering out all orders whose "comments" field starts with "Sub order for" and things seem to be working fine on our end now. I know that according to your description I am technically filtering out the real order and holding on to the fake order, but for our purposes it works out and I see no way to otherwise distinguish real from fake.

So I guess my remaining question is: why are these fake orders coming through the API at all? What possible use could I on the client end have for them?
Edited by WWatson2582 on Feb 19, 2021 09:51 AM

API Support » COM API version disparity Feb 18, 2021 @ 10:04 AM (Total replies: 3)

Not sure how this got posted twice but I'd appreciate it if a moderator could delete one or the other!

API Support » COM API version disparity Feb 17, 2021 @ 10:34 AM (Total replies: 3)

Not sure if this was intended or not, but the latest COM API installers are titled "GAIN GFAPI COM" and "GAIN GFAPI COM x64" yet from the "GF.Api.COM.dll" version resource it is reported that they are in fact installing version

API Support » OSO orders bug in COM API Feb 11, 2021 @ 11:40 AM (Total replies: 12)

It wouldn't let me log in, Chris, so I guess I need a credential reset.

API Support » OSO orders bug in COM API Feb 11, 2021 @ 09:52 AM (Total replies: 12)

Do I understand that you are saying that the "fake" orders are never being filled? When are they cancelled and why do we even see them on the client side of the API if they are not "real"?
Edited by WWatson2582 on Feb 11, 2021 09:53 AM

API Support » OSO orders bug in COM API Feb 11, 2021 @ 09:52 AM (Total replies: 12)

I will investigate this further. How does one specify the server to use with the Gain Trader app? My credentials don't seem to work with anything other than api.gainfutures.com

API Support » OSO orders bug in COM API Feb 10, 2021 @ 04:21 PM (Total replies: 12)

I just heard that a customer of ours testing the COM API with our product had an bracket order go from LONG 3 to SHORT 3 because of this bug but fortunately caught it and were able to flatten their position manually. We are going to disable OSO orders until this is resolved, but this was a real money account so it appears the bug is not limited to the test server.

I would post screencaps of the entire transaction but don't see a way to do that here.

API Support » OSO orders bug in COM API Feb 10, 2021 @ 03:45 PM (Total replies: 12)

We've done this multiple times using our own software calling GFAPI()->Orders->SendOSOOrders() as well as the sample COM API code (modified as given in the first message) always with the same result.

The account is mine ("WWatson2582") using the test server api.gainfutures.com.

In my most recent test, the initial main order was 211862711 and the OCO bracket orders were 211862712 and 211862713. The additional incorrect orders were 211862714 and 211862715.

The net effect of these extra orders is that when the bracket order is supposed to flatten the position, it is instead left short or long depending on which side of the bracket is filled (both orders on that side are filled simultaneously.)

API Support » OSO orders bug in COM API Feb 05, 2021 @ 01:46 PM (Total replies: 12)

I have encountered the following bug in the COM API (latest released version).

After submitting a OSO order using GFAPI()->Orders->SendOSOOrders() method, the two linked orders are submitted twice, or in other words, are each duplicated twice. After the bracket order is completed and the position would normally be again flat, the duplicate order causes an extra closing transaction to be executed, often leaving a non-flat position.

I have created some sample code to demonstrate this using as a base your COM API sample application. All modifications are done to the file CppCOMSampleDlg.cpp. To demonstrate this bug:

1) Add the following global variable declaration to the top of the file:

double lastPrice;

2) Change the CCppCOMSampleDlg::OnPriceChanged method as follows:

void __stdcall CCppCOMSampleDlg::OnPriceChanged(GF_Api_COM::IGFComClientPtr client, GF_Api_COM::IContractPtr contract, GF_Api_COM::IPricePtr price)
lastPrice = price->LastPrice;

log Symbol PriceToString(price->LastPrice) LastVol << std::endl;

3) Change the CCppCOMSampleDlg::OnBnClickedSendorder() as follows:

void CCppCOMSampleDlg::OnBnClickedSendorder()
COrderDlg dlg(GFAPI());
bool orderError = false;

if(dlg.DoModal() == IDOK)

GF_Api_COM::IOrderDraftBuilderPtr builder;
GF_Api_COM::IAccountListPtr accounts = GFAPI()->Accounts->Get();
GF_Api_COM::IAccountPtr account = accounts->GetAt(0);
GF_Api_COM::IAccountIDPtr accountID = account->id;

builder = builder
->WithSide(dlg.m_Buy ? GF_Api_COM::OrderSide_Buy : GF_Api_COM::OrderSide_Sell)
->WithFlags(dlg.m_GTC ? GF_Api_COM::OrderFlags_GTC : GF_Api_COM::OrderFlags_None);

double tickSize = GFAPI()->Contracts->Get_2((LPCSTR)dlg.m_SelectedContract)->tickSize; // To set up bracket order distances later

GF_Api_COM::IOrderDraftPtr mainOrder = builder->Build();

if (GFAPI()->Orders->Drafts->Validate_2(mainOrder)->Count > 0) {
log << "Main Order has invalid parts and will not be sent" << std::endl;
orderError = true;

GF_Api_COM::IOrderDraftBuilderPtr target;

target = target
->WithFlags(dlg.m_GTC ? GF_Api_COM::OrderFlags_GTC : GF_Api_COM::OrderFlags_None)
->WithPrice(lastPrice + 15 * tickSize);

GF_Api_COM::IOrderDraftPtr profitTarget = target->Build();

if (GFAPI()->Orders->Drafts->Validate_2(profitTarget)->Count > 0) {
log << "Profit Target Order has invalid parts and will not be sent" << std::endl;
orderError = true;

GF_Api_COM::IOrderDraftBuilderPtr loss;
loss = loss
->WithFlags(dlg.m_GTC ? GF_Api_COM::OrderFlags_GTC : GF_Api_COM::OrderFlags_None)
->WithPrice(lastPrice - 15 * tickSize);

GF_Api_COM::IOrderDraftPtr stopLoss = loss->Build();

if (GFAPI()->Orders->Drafts->Validate_2(stopLoss)->Count > 0) {
log << "Stop Loss Order has invalid parts and will not be sent" << std::endl;
orderError = true;

if (!orderError) {
GF_Api_COM::IOrderListPtr orders = GFAPI()->Orders->SendOSOOrders(mainOrder, profitTarget, stopLoss, GF_Api_COM::OSOGroupingMethod_ByFirstPrice);
if (!orders)
log << "Cannot send OSO orders" << std::endl;
log << "OSO Orders have been sent. " << std::endl
GetAt(0)->id->Value GetAt(0)->ToString << std::endl
GetAt(1)->id->Value GetAt(1)->ToString << std::endl
GetAt(2)->id->Value GetAt(2)->ToString << std::endl;

To demonstrate a bug with OSO orders after connecting to the GAIN server:
1) Subscribe to prices for a contract, e.g. ESH21
2) Click on the "Send Order" button in the main application dialog box.
3) Assure that the Order dialog box is completed with a Market Buy order for the same symbol subscribed to in step #1

An OSO bracket order will be constructed and submitted using a 15-tick Limit order and 15-tick Stop order. Rather than just the primary order and two linked orders submitted, you should see duplicate orders for each of the linked orders.

API Support » Wrong platform linked to new COM API release? Feb 04, 2021 @ 01:20 PM (Total replies: 2)

Can you verify that the newest COM API version released on this page:
linked to the "Download GF API (COM 64-bit)" button is actually a 64-bit version. I think the 32-bit version got cross-linked to both platform download buttons.

New Feature Requests » Developer Forum feature request Feb 04, 2021 @ 01:02 PM (Total replies: 1)

It would be useful if you had a topic somewhere in this forum that we can subscribe to and be automatically notified when you release updates, such as the recent release of the new COM API libraries.

API Support » GAIN API COM Installer quirk Jan 04, 2021 @ 08:58 AM (Total replies: 1)

When the GAIN GFAPI installer completes, the dialog box which offers the "Finish" button has a checkbox item that reads "Launch GAIN GFAPI COM [x64]" which appears to do absolutely nothing - perhaps it should launch some version info notes or am I missing something?


API Support » GAIN API COM installation and version query Dec 30, 2020 @ 10:13 AM (Total replies: 3)

1) If we choose to use the supplied .exe to install the GAIN API COM components, is there a command line argument we can supply from our installer that will operate the GAIN API COM installer in "silent" mode (not requiring any user interaction)?

2) Must GAIN API COM components be installed to the C:\Program Files\GAIN folder (or its 32-bit equivalent) or can we install it to a folder of our own designation?

3) Is there an API call or other mechanism to see what version of the GAIN API COM components are currently installed? We issue a lot of updates and would rather not reinstall/re-register these components every time if the latest version is already installed.

Thanks for your replies!

API Support » New bug in GAIN COM API Oct 26, 2020 @ 08:36 AM (Total replies: 2)

The previous bug I reported here:

appears to be fixed in the latest release, but that release introduces a new serious bug. Over the weekend, I managed to drill down to expose the following information that should help you fix this.

Once the WithContractKinds() method has been called on the ISymbolLookupExpressionBuilder object, no other expression methods can be executed on the same object (such as WithContractType(), WithHasOptions() or WithOptionType) without causing an exception to be raised when the Build() method is later executed on that ISymbolLookupExpressionBuilder object.

The exception description is "Tree must have single root. Push more operators." The order in which these methods are called on the ISymbolLookupExpressionBuilder object do not seem to matter.

Scott Watson

API Support » COM API: Sep 07, 2020 @ 03:01 PM (Total replies: 2)

To be clear - it appears that it's only the WithContractKinds method that's broken.


API Support » COM API: Sep 07, 2020 @ 02:05 PM (Total replies: 2)

For COM API users, ISymbolLookupExpressionBuilder appears to be broken. For example,

GF_Api_COM::ISymbolLookupExpressionBuilderPtr expressionBuilder;
CComSafeArray kinds(10);
expressionBuilder = expressionBuilder->WithContractKinds(kinds);

...will cause an exception to be thrown. This appears to be a known bug since this sort of operation has been commented out in the CppCOMSample project in the file CppCOMSampleDlg.cpp around line 671.

Is there a fix coming from this soon or is there an alternate method to limit the kinds of contracts returned by GFAPI()->Contracts->Lookup->ByCriteria?

Scott Watson

API Support » GAIN API COM Example problem Jul 15, 2020 @ 10:24 AM (Total replies: 2)

I am having a problem with the CppCOMSample solution as follows:

1) I downloaded and installed the newest versions of the 32 and 64 bit API for COM users from https://gainfutures.com/gainfuturesapi/documentation as well as the newest version of the CppCOMSample solution.

2) I verified with regedit.exe that the libid key 20A98AD2-2C0F-4192-A53D-0F6189ED5B2B is pointing to the proper directories for the 32-bit and 64-bit versions.

3) I loaded the CppCOMSample with Visual Studio 2019 and built the 32-bit Debug application. When I run it and connect with my username and password, it connects properly and I am able to perform a Symbol Lookup operation with no errors. If I attempt to connect with a known incorrect username and/or password, CCppCOMSampleDlg::OnLoginFailed is called with failReason set to FailReason_InvalidUserOrPassword (0).

4) I built the 64-bit Debug version and executed it. When I attempt to logon, one of two things happens:
a) Most often, _Release() method in comip.h is called with a read access violation exception. I'll include the call stack at the bottom of this message.
b) Less often, CCppCOMSampleDlg::OnLoginFailed is called with failReason set consistently to 1366336 (decimal) - this bogus failReason code may be a separate and unrelated bug.

5) I get the same result for the 64-bit version when I attempt to logon with a known incorrect username/password.

6) Chris M. has verified that my account is valid.

Best regards,
Scott Watson

When the exception is thrown as described in 4a above, the call stack looks like:
> CppCOMSample.exe!_com_ptr_t>::_Release() Line 969 C++
CppCOMSample.exe!_com_ptr_t>::~_com_ptr_t>() Line 224 C++
CppCOMSample.exe!CCppCOMSampleDlg::OnAccountSummaryChanged(_com_ptr_t> client, _com_ptr_t> account, _com_ptr_t> currency) Line 315 C++
[External Code]
CppCOMSample.exe!AfxInternalPumpMessage() Line 183 C++
CppCOMSample.exe!CWinThread::PumpMessage() Line 900 C++
CppCOMSample.exe!AfxPumpMessage() Line 190 C++
CppCOMSample.exe!CWnd::RunModalLoop(unsigned long dwFlags) Line 4661 C++
CppCOMSample.exe!CWnd::CreateRunDlgIndirect(const DLGTEMPLATE * lpDialogTemplate, CWnd * pParentWnd, HINSTANCE__ * hInst) Line 470 C++
CppCOMSample.exe!CDialog::DoModal() Line 633 C++
CppCOMSample.exe!CCppCOMSampleApp::InitInstance() Line 63 C++
CppCOMSample.exe!AfxWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 37 C++
CppCOMSample.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 26 C++
[External Code]