API Support Forum
User Profile

Viewing User Profile for: MFrasson3344


About

Nov 09, 2015 05:19 PM

Jul 30, 2023 12:16 PM

Jul 30, 2023 12:17 PM



Post Statistics
MFrasson3344 has contributed to 45 posts out of 5677 total posts (0.79%) in 3301 days (0.00 posts per day).

20 most recent posts:

API Support » SocketError + Expected TopMsgTypeTagAttribute on Last GFAPI version Jul 30, 2023 @ 12:16 PM (Total replies: 1)

The problem seems to occur only with older versions of Visual Studio 2013/2015.
Using for example Visual Studio 2019 everything works.
Mauro frasson


API Support » SocketError + Expected TopMsgTypeTagAttribute on Last GFAPI version Jul 29, 2023 @ 08:33 AM (Total replies: 1)

I'm trying to use last GFAPI version (4.11.519.358).
Connection works, but when i try to request something (historical data, real time subscriprion, search for a contract) i have a disconnection from your side (the event "Disconnected" is raised).

Below the error message details. Any idea?

Reason = SocketError (0)
Exception = "Expected TopMsgTypeTagAttribute"

StackTrace = " in GF.ProtoSharp.Serialization.DeserializeMsg.DeserializeTopMsg[TBase](Func`2 getTypeFromTag, MessageReader msgReader) in GF.Api.Impl.Connection.ConnectProtoClient.c__DisplayClass0_0`2.b__0(Byte[] bytes) in LanguageExt.Option`1.Map[B]...
Mauro frasson

Edited by MFrasson3344 on Jul 29, 2023 08:34 AM

API Support » Unable to find contracts Jun 05, 2023 @ 07:32 PM (Total replies: 1)

We solved by changing API version.
Mauro frasson

Edited by MFrasson3344 on Jun 05, 2023 07:34 PM

API Support » Unable to find contracts Jun 05, 2023 @ 10:17 AM (Total replies: 1)

Several of our users report problems with instruments and we also experience them both in demos and in our dev account.

In practice, there seems to be some problems finding contracts using the Lookup.ByCriteria function. After the lookup command, the SymbolLookupReceived event is received but no contracts are found.
If the search does not work the program cannot subscribe to the instrument feed or do anything else.

2/3 weeks ago we started having the problem in our dev account, but now the problem has spread to demos and maybe real accounts (to be verified).

In the past, 1 year ago or more, there was the same problem.
This is clearly very urgent. Thanks.

Mauro Frasson
(Overcharts)
Mauro frasson


API Support » Instruments not found Nov 08, 2022 @ 05:03 AM (Total replies: 2)

After 2 hours from my post everything was resolved. Perfect! Thank you.
Mauro frasson


API Support » Instruments not found Nov 07, 2022 @ 09:45 AM (Total replies: 2)

For a few days we (Overcharts) have been having problems with some instruments (contracts).
Some contracts such as "ESZ22" or "NQZ22" (but in general all ES and NQ, but also other instuments) cannot be found. This happens both in our Developer account, but also in the Demo accounts. I suspect that some changes have been made to the servers that have caused some problems.
To reproduce the case, just search for example the ESZ22 or NQZ22 contract on a demo account using the API and nothing is found. I have not tried using a real account.

Other instruments such as MESZ22 are found without problems.

If the contract is not found, it is not possible to download historical data, subscribe to real time, place orders etc.

Thank you for your help.
Mauro frasson


API Support » Open position P/L issue Dec 02, 2020 @ 07:58 AM (Total replies: 9)

Ok perfect, thanks.
No problem managing subscriptions manually. If it is not already written in the documentation it is an important thing to add.
Mauro frasson


API Support » Open position P/L issue Dec 01, 2020 @ 05:46 PM (Total replies: 9)

I investigated more and understood what is the exact issue of why Open P/L does not update:
It seems that the GF API does not automatically subscribe to the quotes for instruments with the position open (which OEC API does instead). Did I forget to set some parameters or is it really necessary to subscribe the quotes manually to have the Open P/L updated?
Mauro frasson


API Support » Open position P/L issue Dec 01, 2020 @ 11:23 AM (Total replies: 9)

I have tried right now with Gain Trader 4.0 and it works (Open P / L is updated). I'll try to use the GF API nuget version and see what happens.
Mauro frasson

Edited by MFrasson3344 on Dec 01, 2020 11:23 AM

API Support » Open position P/L issue Dec 01, 2020 @ 10:46 AM (Total replies: 9)

Yes I know about the GF API on nuget, but you have built them by merging many other dlls under a single dll and this does not work with dynamic loading of dlls. So I get the single dlls from Gain Trader. Actually the issue also occurs with July dll releases (or maybe earlier).
Mauro frasson


API Support » Open position P/L issue Dec 01, 2020 @ 10:07 AM (Total replies: 9)

Hi Chris,

I tried now another time with my developer account (but it also happens with real accounts for this reason I suspect it is a GF API 4.0 issue), and it seemed to work because today I had not opened and closed the position previously.
So I have opened and closed the same position several times using OEC API. Then I opened it with OEC API. I logged out from OEC API and reconnected with GF API and the issue occurred.

The issue probably occurs if the position has already been opened and closed multiple times (or at least one) during the day.

So try to open and close the position 2 or 3 times with OEC API. Then open it again always with OEC API. Then log out from OEC API and reconnect with GF API.
Mauro frasson


API Support » Open position P/L issue Nov 30, 2020 @ 03:50 PM (Total replies: 9)

Hi guys!

Maybe we found a possible bug:

We tried to open a position using the OEC API (3.5), so we closed the connection and reconnected to the same account using the new GF API 4.0.
The position does not receive the P/L update (GF API 4.0) if it was initially opened with the OEC API. The AvgPositionChanged event is not raised to update Open P/L.

Everything works if the position is initially opened with GF API 4.0 instead of OEC API 3.5.

There seems to be some incompatibility issue between the two API versions if the position is initially opened with the OEC API.

Unfortunately for this reason we were forced to immediately revert to the old OEC API until this problem is fixed. Many of our users use different applications and have reported this issue to us and we were able to reproduce it immediately too. For example, they open a position with an application (for example OEC Trader 3.5) and manage it with our application (Overcharts) which uses the new GF API 4.0.
GF API version is the very latest available with Gain Trader Developer 4.0.

Thank you for you help.
Mauro frasson

Edited by MFrasson3344 on Nov 30, 2020 04:33 PM

API Support » Trailing Stop and Trailing Stop Limit order - version issue Jun 09, 2020 @ 07:07 AM (Total replies: 2)

There is a bug in the "Versions" collection (GF API) of a Trailing Stop and Trailing Stop Limit order.

I'm using the new GF API, but i found the issue with old OEC api and with "Gain Trader Developer" application (lastest version) too.
I used a Demo account + developer account (I hope the problem is not in the live accounts! please check).

To reproduce the issue:
Place a Trialing Stop order and wait for it to follow the market. The first automatic change to the order is performed correctly, but after this the "Versions" collection always contains the same data that correspond to the second version of the order. This is an example of the order versions collection:

{Sell 1 ESM20 3194.00 Trailing Stop, Ref Price: 3197.5, Delta: 0} (Order creation version)
{Sell 1 ESM20 3194.25 Trailing Stop, Ref Price: 3197.5, Delta: 0} (first auto modification) --> OK
{Sell 1 ESM20 3194.25 Trailing Stop, Ref Price: 3197.5, Delta: 0} (second auto modification) --> NOT OK!! Same as the first modification
{Sell 1 ESM20 3194.25 Trailing Stop, Ref Price: 3197.5, Delta: 0} NOT OK! Same as the first modification
{Sell 1 ESM20 3194.25 Trailing Stop, Ref Price: 3197.5, Delta: 0} NOT OK! Same as the first modification
{Sell 1 ESM20 3194.25 Trailing Stop, Ref Price: 3197.5, Delta: 0} NOT OK! Same as the first modification
{Sell 1 ESM20 3194.25 Trailing Stop, Ref Price: 3197.5, Delta: 0} NOT OK! Same as the first modification

We are near to release a new version of our application with new GF API and i would like to understand if this is an API issue or a server issue or both.

Thank you for your collaboration.
Mauro frasson

Edited by MFrasson3344 on Jun 09, 2020 07:08 AM

API Support » "Market if touched" order type does not work properly in demo/developer accounts Jun 08, 2020 @ 02:25 PM (Total replies: 1)

The "Market if touched" order type seems
    not to work properly with demo / developer accounts:

    1) Enter a "Market if touched" order with quantity 10
    2) Change the quantity to 1
    3) Wait for the order execution

    The order is executed with quantity 10 and not 1.
    Mauro frasson


    API Support » SendOSOOrders instead of SendLinkedOrders Mar 19, 2020 @ 05:41 AM (Total replies: 1)

    I have seen that in the new (not yet official) API versions the SendLinkedOrders function has been deprecated. It has been replaced by SendOSOOrders. Do you confirm this?
    Mauro frasson


    API Support » Error when i call GF.Api.Impl.GFApi.CreateClient() Jan 31, 2020 @ 08:02 AM (Total replies: 10)

    NuGet package contains only 4 DLLs:
    GF.Api.dll
    GF.Api.Impl.dll
    GF.Api.Values.dll
    GF.Common.dll

    All others are embedded inside GF.Api.Impl.dll. This is my problem.
    In my case, to load them dynamically from a different path than the executable folder, I need to have all DLLs (not embedded).

    So I have 2 solutions:

    Solution n. 1:
    I put the 4 NuGet DLLs in the executable folder (not the best solution in my case);

    Solution n. 2:
    I insert all the DLLs (10+) in the folder where I want and dynamically load them.
    Mauro frasson

    Edited by MFrasson3344 on Jan 31, 2020 08:03 AM

    API Support » Error when i call GF.Api.Impl.GFApi.CreateClient() Jan 28, 2020 @ 02:13 PM (Total replies: 10)

    It's all right on my side. I added NuGet packages from the beginning exactly as you described.
    I probably couldn't explain myself well.
    I'll let you investigate using the test project above.

    Please answer only this question for now:
    What are the DLLs embedded in GF.Api.Impl.dll?

    Thanks
    Mauro frasson


    API Support » Request Daily Historical Data Jan 28, 2020 @ 11:05 AM (Total replies: 1)

    I am subscribing to daily historical data using this function:

    client.Subscriptions.Bars.Subscribe(contract.ID, client.Subscriptions.Bars.Duration.Create(StartingDate, EndingDate, GF.Api.Subscriptions.Continuity.OneTime), client.Subscriptions.Bars.Description.CreateDays(1))

    The callback occurs both on BarsReceived and on DayBarsReceived. Which one should I consider? Is my solution the best way to request daily historical data?

    Thanks
    Mauro frasson


    API Support » Error when i call GF.Api.Impl.GFApi.CreateClient() Jan 28, 2020 @ 10:51 AM (Total replies: 10)

    I use .NET Framework.

    Other information:

    The issue is that in the case of dynamic loading of DLLs, if they are not in the executable folder, loading does not find some of them. For example the SimpleInjector.dll and GF.SimpleInjector.dll and so on are not found. Basically all the DLLs embeded into GF.Api.Impl.dll are not found.

    In fact, if instead of taking them from NuGet I take them from the "GAIN\Trader Dev 4.0" folder (all the DLLs contained in) and copy them into the bin/dll folder of the test console application, everything works.
    In short, I need to physically have all the DLLs you use so that I can find and load them one by one. This solves the issue.

    So my question is:
    What exactly are all the DLLs you embed inside GF.Api.Impl.dll?
    Mauro frasson

    Edited by MFrasson3344 on Jan 28, 2020 10:53 AM
    Edited by MFrasson3344 on Jan 28, 2020 10:54 AM

    API Support » Error when i call GF.Api.Impl.GFApi.CreateClient() Jan 27, 2020 @ 01:09 PM (Total replies: 10)

    To reproduce the issue, try this "Visual Basic" console application:

    Add the 4 GF.API dlls to the project references and set "Copy Local" = FALSE.
    GF.Api.Values.dll
    GF.Common.dll
    GF.Api.dll
    GF.Api.Impl.dll

    Run 2 tests:

    First Test:
    1) Copy the 4 GF.API dlls in the folder "bin\Debug\dll\" (the DLLs will be loaded by AppDomain.CurrentDomain.AssemblyResolve)
    2) Run -> error!

    Second Test:
    1) Copy the 4 GF.API dlls in the "bin\Debug\" folder -> the same as the .exe (DLLs will be loaded automatically)
    2) Run -> OK!


    This is the console app code:


    Sub Main()
    AddHandler AppDomain.CurrentDomain.AssemblyResolve, AddressOf MyResolveEventHandler

    Main_Real()
    End Sub


    Public Sub Main_Real()
    Dim GFclient As GF.Api.IGFClient = GF.Api.Impl.GFApi.CreateClient()
    End Sub


    Private Function MyResolveEventHandler(ByVal sender As Object, ByVal args As ResolveEventArgs) As System.Reflection.[Assembly]
    Try
    Dim DLL_Name As String = New System.Reflection.AssemblyName(args.Name).Name

    If (String.IsNullOrWhiteSpace(DLL_Name) = False) Then
    Dim Path As String = System.IO.Path.Combine(My.Application.Info.DirectoryPath, "dll")

    Dim AssmbFullPath As String = System.IO.Path.Combine(Path, DLL_Name & ".dll")

    If (System.IO.File.Exists(AssmbFullPath) = True) Then
    Return System.Reflection.Assembly.LoadFrom(AssmbFullPath)
    End If
    End If
    Catch ex As Exception
    End Try

    Return Nothing
    End Function
    Mauro frasson