| API Support » IPrice exceptions Sep 13, 2024 @ 08:30 AM (Total replies: 7) | |||||
|
Any updates on this? We have a client eager to use the newest API release. |
|||||
| API Support » IPrice exceptions Aug 29, 2024 @ 05:32 PM (Total replies: 7) | |||||
|
However, you don't need to reference my code at all - just insert the following at line 282 in CppCOMSampleDlg.cpp in your CppCOMSample project, put a breakpoint there, and once connected, checkmark the "Show price updates" and click on the "Subscribe Prices" button and select an active contract, like "ESZ24". When your breakpoint is hit, just single-step to see the exception thrown: (at line 282:) GF_Api_COM::PriceFields pf = price->Fields; Edited by WWatson2582 on Aug 29, 2024 05:32 PM |
|||||
| API Support » IPrice exceptions Aug 29, 2024 @ 05:19 PM (Total replies: 7) | |||||
|
This is immediately upon entry to the OnPriceTick method (see line 251 in GFAPIEvents.h included with your CppCOMSample), so a minimalist example would look like: void __stdcall CDPBridge::OnPriceTick(GF_Api_COM::IGFComClientPtr client, GF_Api_COM::IContractPtr contract, GF_Api_COM::IPricePtr price) { GF_Api_COM::PriceFields pf = price->Fields; } |
|||||
| API Support » IPrice exceptions Aug 28, 2024 @ 12:51 PM (Total replies: 7) | |||||
|
Using the COM interface API for version 4.15.726.321, in the OnPriceTick callback, when I try to do anything with the "Fields" member of the funtion's "price" parameter, I get an immediate _com_issue_errorex exception thrown. For example, if I do the following immediately in this function, the exception occurs: GF_Api_COM::PriceFields pf = price->Fields; The Visual Studio Debugger traces this exception to GF_Api_COM::PriceFields GF_Api_COM::IPrice::GetFields( ) in the file GF.Api.COM.tli - there is no stack trace attached to the exception. Is this something I'm doing wrong (it worked in previous versions)? Edited by WWatson2582 on Aug 28, 2024 12:52 PM |
|||||
| API Support » Connection problem Aug 13, 2024 @ 02:45 PM (Total replies: 1) | |||||
|
I have been asked to provide tech support for a customer of my client and part of that is upgrading my client's application to utilize the most recent version of the API. After installing the newest COM API version, the very same account I use to log into this forum is being supplied to the "Connect" dialog box in the CppCOMSample_2019 application. It results in the following error message: "Disconnected due to InvalidUserOrPassword". I had a problem logging into this developer forum and was supplied a second password to try. This password will not log me into the developer forum, but when I use it with the CppCOMSample_2019 application it does connect but then throws an exception as follows: ""The server threw an exception. (Exception from HRESULT: 0x80010105 (RPC_E_SERVERFAULT)) at System.RuntimeType.ForwardCallToInvokeMember(String memberName, BindingFlags flags, Object target, Int32[]... (1)" I could sure use some help getting this up and running. |
|||||
| API Support » Socket errors Jul 09, 2021 @ 08:36 AM (Total replies: 9) | |||||
|
I now have a second client reporting the same "socket errors" causing disconnection. Notably, once this error occurs, they are often unable to reconnect as the server sends a "user already connected" rejection message. I have both users contact GAIN account and contact details - please let me know how to forward them to you so you can follow up with them and hopefully get this solved. I am not seeing any consistency in their actions causing the socket errors - they appear to happen randomly without any particular user action, without regard to data flow or market speed. They are both using the latest released COM API version (4.0.3.58). Typically all we see from the logging mechanism is something like this: 07/08/2021 11:33:13 - OnDisconnected(): Disconnected: reason [Socket error] |
|||||
| API Support » Socket errors Apr 29, 2021 @ 08:40 AM (Total replies: 9) | |||||
|
By the way, when he gets a socket error, the OnDisconnected event is called in our code with reason containing DisconnectionReason_SocketError and reason containing "Socket error" and that's all we apparently have to work with. Is there any API settings we can twiddle that would make his connection more tolerant to momentary local disconnects or timeouts? Edited by WWatson2582 on Apr 29, 2021 08:42 AM |
|||||
| API Support » Socket errors Apr 29, 2021 @ 08:30 AM (Total replies: 9) | |||||
|
Good morning, Chris: His ports 9210 and 9211 are working - this is not a case of unable to connect - it runs for a while and then randomly disconnects. GAIN's is the only server he is reporting having problems with, and he is our only client reporting this sort of problem. Here is his latest response to me: -------------- I continue to have IRT problems disconnecting from Gain. It remains random, maybe 6-12x a day. Today not a single drop until 11:07 then about 6x in the afternoon. 1. Ports 9210 and 9211 are working. Attached is the netstat log file that shows IRT and Gain IP and Port addresses. Feel free to forward it to Gain. It shows Gain ("trader.exe") and Investor RT connected to Gain IP 66.76.151.30 through Port 9210 and 9211. 2. Per Gains instructions, I ran ping test on 173.219.221.161 and 64.74.108.94 without any issues. No drops and RT times around 30ms. 3. I ran tracert to prod.gainfutres.com and got 12 hops to suddenlink.net (per Gains instructions.) I did get a bunch of timeouts after reaching suddenlink,net but I don't think that matters. --------------------- He forwarded to us a file containing netstat results that appears unremarkable. Where is the "API Log" located? Is there one created internally by the COM API or is this something the COM API client (us) are supposed to be maintaining through (for example) API events like OnErrorOccurred? |
|||||
| API Support » Socket errors Apr 26, 2021 @ 08:14 AM (Total replies: 9) | |||||
|
We have a client that reports having many socket error disconnections with GAIN COM API and did not have them with previous API. Is there a way we can diagnose this further or should he contact GAIN support directly for this? |
|||||
| 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 4.0.3.37.exe" and "GAIN GFAPI COM x64 4.0.3.37.exe" yet from the "GF.Api.COM.dll" version resource it is reported that they are in fact installing version 4.0.3.45 |
|||||
| 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.) |
|||||