Glad the duplicate order is gone now, Robert.
I was not suggesting a multi-threaded design to avoid "sleep" between requests and responses. Just an event-oriented design. I am not a VBA/Excel macro practitioner, but I believe they do have an event model that supports an event oriented/reactive application design that entirely removes the need for blocking/wait/sleep between request and response.
Not sure what to tell you about the DAX order not working other than the standard checklist. Are you sure your code properly catches and reports all API errors? If you can't get an error to display, this would be a good case for the TWS log, since you'd want to know what TWS thinks you have sent and what the response is.
Not sure whether the DAX contract needs additional fields initialized. We avoid the guess work, as a matter of practice, since we never create our own Contract objects. We rather make . queries when the client starts (with the fewest fields that uniquely describe the instrument, usually just with the local symbol such as "FDXM SEP 22", type, and maybe exchange) and then use the returned fully populated contract object for all requests that require one.
闯ü谤驳别苍
On Fri, Jul 29, 2022 at 07:26 AM, Metrodus79 wrote:
1. "One area I'd review is the code that determines the next order ID. As the Placing Orders chapter of the API Reference Guide suggests, clients generally maintain their own sequence of order IDs and do not make API calls for the nextOrderId unless they somehow lose the sequence. During the initial connection request, clients are automatically informed of the next valid order ID and, from that point on, simply increment an internal nextOrderId field as needed. "
So for my understanding now, it is not necessary to make always a request for a validOrderid and it save process time to increment the order id in a own sub. I get the first valid id with the first connection in the morning. I implemented this and of course the problem with the duplicate order id is gone :)
2. "our code needs to be structured event oriented as well and needs to wait for the arrival of a callback (or the corresponding error) and not sleep for a fix period of time after the request."
The Code really wait and not sleep. There is a timer in the backround who started the code again and then it follows a validation phase to check the answer from the API. I'm use unique strings that the program always know the correct sequence entry point. IMO there is no way to use multithread with excel so i have to do everything step by step. Of course this need time but still now it is not relevant for my trading.
...
My question is now if i have to change anything in the contractinfo object in the way to get a response from TWS via API. IMO it is strange that the problem started for me with the change of the exchange from DTB to EUREX. Do you or anyone know something about this or have the same issue with requests on EUREX-Exchange via API and TWS?
