¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 ¿ªÔÆÌåÓý

Re: Strange Behavior After TWS Update on Old API

 

It must be a bug because this behavior occurs only on the paper account, not on the live account.

El s¨¢b, 25 ene 2025 a las 21:46, ´³¨¹°ù²µ±ð²Ô Reinold via (<TwsApiOnGroupsIo=[email protected]>) escribi¨®:

Thank you for the update.

You may have seen the Post "One more issue/thing about reqexecutions" from Thursday, where @joanmarcel119 describes how to get reqExecutions working in TWS. It looks like TWS will not send historical execution reports until you have opened the "New Window" -> "Trade History" window. I now remember that we had this discussion a couple times before.

I just confirmed (for a paper account on Linux and a 10.17 Java API) that "stable" TWS 10.19.2p, "stable" TWS 10.30.1t, and "latest" TWS 10.33.1e show the same behavior as @joanmarcel119 describes:

  • When I start TWS and connect a client that requests historical executions, an empty list is returned
  • When the "New Window" -> "Trade History" window is open, the client receives execution and commission reports for all trades that window shows. In my case, Trade History is set to show "For Last 7 Days" and it contained 11 trades from 1/19 to 1/23.
  • For stable TWS 10.19.2p, the window must stay open, or client connection/requests result in an empty list.
  • For stable TWS 10.30.1t and latest TWS 10.33.1e, the simple fact of opening and closing the window suffices. Those versions return all expected reports even if the window is closed again.

This will not work for IBGW since the gateway does not implement any of the TWS windows (including Trade History). So IBGW will always be limited to the executions since midnight.

The fact that the TWS window has to be open/opened at least once for reqExecutions to return execution and commission reports can be viewed as a bug, but it must have been around for a while, was not introduced in 10.30 and is present in the currently stable and latest TWS versions.

So I must assume your issues were not related to the TWS versions per se. Maybe it is really time to move from the non-IBKR ibPy API (that has not been updated for 9 years and that the author calls "superfluous" since 9.73) to the IBKR provided Python API.

´³¨¹°ù²µ±ð²Ô

?

?

On Sat, Jan 25, 2025 at 01:42 PM, Adam S. wrote:
Sorry, just seeing this.? Yes, TWS had the trades in its trade history.? Once I updated TWS to 10.33 those very same trades became accessible to my by API using same code again.
?


Re: C++ preventing EReader reading when socket is closed

 

I cannot replicate your problem. When I shutdown TWS manually, the EReader stops properly and calls EWrapperImpl::connectionClosed() which is what is supposed to happen.
?
A 509 error is not what is expected. A 509 error means your code is trying to read on a closed socket which is a bug. By commenting out "stop()" your EReader thread has hung in an infinite wait and will never end until you force the program to stop.
?
What version TWS and API are you using? Are you on Windows or Linux?My test just now is using the latest version of TWS and latest API running on Windows.


Re: C++ preventing EReader reading when socket is closed

 

?Not sure if this is the right topic but I got a problem with these newly added code in EClientSocket::eDisconnect.

void EClientSocket::eDisconnect(bool resetState) {

// Stop EReader thread to avoid 509 error caused by reading on a closed socket.

? if (m_pEReader)

? ? m_pEReader->stop();

...
When TWS is shutdown manually, the code will hang at m_pEReader->stop(). The call stack is:
?
> ? ?APITWS.dll!EClientSocket::eDisconnect(bool resetState) Line 241 ? ?C++
? ? ?APITWS.dll!EClientSocket::onClose() Line 370 ? ?C++
? ? ?APITWS.dll!EClientSocket::receive(char * buf, unsigned int sz) Line 274 ? ?C++
? ? ?APITWS.dll!EReader::onReceive() Line 199 ? ?C++
? ? ?APITWS.dll!EReader::processNonBlockingSelect() Line 181 ? ?C++
? ? ?APITWS.dll!EReader::readToQueue() Line 101 ? ?C++
? ? ?APITWS.dll!EReader::readToQueueThread(void * lpParam) Line 93 ? ?C++
?
Commenting out m_pEReader->stop() the code runs happily and will generate a 509 error as expected.
?


Re: Strange Behavior After TWS Update on Old API

 

Thank you for the update.

You may have seen the Post "One more issue/thing about reqexecutions" from Thursday, where @joanmarcel119 describes how to get reqExecutions working in TWS. It looks like TWS will not send historical execution reports until you have opened the "New Window" -> "Trade History" window. I now remember that we had this discussion a couple times before.

I just confirmed (for a paper account on Linux and a 10.17 Java API) that "stable" TWS 10.19.2p, "stable" TWS 10.30.1t, and "latest" TWS 10.33.1e show the same behavior as @joanmarcel119 describes:

  • When I start TWS and connect a client that requests historical executions, an empty list is returned
  • When the "New Window" -> "Trade History" window is open, the client receives execution and commission reports for all trades that window shows. In my case, Trade History is set to show "For Last 7 Days" and it contained 11 trades from 1/19 to 1/23.
  • For stable TWS 10.19.2p, the window must stay open, or client connection/requests result in an empty list.
  • For stable TWS 10.30.1t and latest TWS 10.33.1e, the simple fact of opening and closing the window suffices. Those versions return all expected reports even if the window is closed again.

This will not work for IBGW since the gateway does not implement any of the TWS windows (including Trade History). So IBGW will always be limited to the executions since midnight.

The fact that the TWS window has to be open/opened at least once for reqExecutions to return execution and commission reports can be viewed as a bug, but it must have been around for a while, was not introduced in 10.30 and is present in the currently stable and latest TWS versions.

So I must assume your issues were not related to the TWS versions per se. Maybe it is really time to move from the non-IBKR ibPy API (that has not been updated for 9 years and that the author calls "superfluous" since 9.73) to the IBKR provided Python API.

´³¨¹°ù²µ±ð²Ô

?

?

On Sat, Jan 25, 2025 at 01:42 PM, Adam S. wrote:

Sorry, just seeing this.? Yes, TWS had the trades in its trade history.? Once I updated TWS to 10.33 those very same trades became accessible to my by API using same code again.
?


Re: Strange Behavior After TWS Update on Old API

 

Sorry, just seeing this.? Yes, TWS had the trades in its trade history.? Once I updated TWS to 10.33 those very same trades became accessible to my by API using same code again.


One more issue/thing about reqexecutions

 

Hi there,

I've checked some of the older posts about reqExecutions and some of them are about the same, not getting the executions even the trade history has been set to x days before. I can explain my findings about this, maybe this can help somebody.

I'm using TWS 10.30 and I can replicate the same behaviour on IBG 10.30

This behaviour just occurs on the PAPER account:
- You won't get the executions until you?visit the trade history page first. Once you click on the Trade History button or keyboard shortcut on TWS (ALT+A+T) then you are able to request the reqexecutions and you get them back on the?execDetails and execDetailsEnd events.?

I can send a combination of keys to the TWS to solve this issue while testing on the Paper account but I can not replicate this on the IB Gateway.?

Hope this helps


Improvements to Intraday Momentum Strategies Using Parameter Optimization and Different Exit Strategies

 

I published a paper on Improvements to Intraday Momentum Strategies Using Parameter Optimization and Different Exit Strategies, for which I used the TWS API for live validation:

Abstract

Building on the results of Zarattini, C., Aziz, A., & Barbon, A. (2024). Beat the market: An effective intraday momentum strategy for S&P500 ETF (SPY), we explore improvements to noise boundary based intraday momentum strategies by investigating different exit strategies and applying parameter optimization to all parameters of the strategies. We show that the returns of the momentum strategy can be significantly improved by such an approach. The best results are achieved with exits based on VWAP, VWAP & Ladder and Ladder exit strategies, with Sharpe ratios over 3.0 and annualized returns of over 50%, which are significant improvements against the baseline strategy.


All feedback welcome


Re: Strange Behavior After TWS Update on Old API

 

My api is an extremely basic c++ implementation that hasn't been updated in 18 years.? I never had a problem with it until 10.30.? I'm hoping 10.33.1 solves my issues also.


Re: Strange Behavior After TWS Update on Old API

 

TWS and IBGW 10.30 stable are perfectly fine to use. I run them with clients at API level 173 (that is something like 10.17.01) without any issues.

When you run IBKR provided TWS API implementations (such as the Java API I use), TWS API is very robust and provides backward and forward compatibility. Meaning that old clients work with newer TWS/IBGW and vice versa. During connection, the two negotiate the common TWS API level they use so that only messages known at that level are to be exchanged.

But IBKR provided TWS API implementations are even robust in case a client with an older TWS API gets exposed to a message from a newer version. That should not happen but, apparently does in some cases with TWS/IBGW 10.30 and some others. But that does not cause any issues, because:

  • Message fields introduced by newer API versions are always added at the end of the message
  • The bytes for all fields are accounted for in the message length header field
  • EDecoder for older clients reads the entire message (even the bytes and fields it does not understand) and simply ignores any extra fields and bytes that it is not aware of.

Custom or non-IBKR TWS API implementations may not implement all these safeguards and would fail in these cases.

´³¨¹°ù²µ±ð²Ô

?
?
?
?
On Tue, Jan 21, 2025 at 08:17 PM, Lewis_Tang wrote:

So it seems 10.30 is not really a "stable" version. For those (including me) who are still on 10.19, should be directly update to 10.33 ?


Re: Strange Behavior After TWS Update on Old API

 

So it seems 10.30 is not really a "stable" version. For those (including me) who are still on 10.19, should be directly update to 10.33 ?


Re: C++ IBKR API implementation and biddll.lib Intel Math Library

 

@´³¨¹°ù²µ±ð²Ô Reinold
?
Yes, following the instructions of "Intel_lib_build.txt" was one of the first things that I did.
They say:
In IntelRDFPMathLib20U2/LIBRARY directory execute the following commands:
nmake -fmakefile.mak CC=cl CALL_BY_REF=0 GLOBAL_RND=0 GLOBAL_FLAGS=0 UNCHANGED_BINARY_FLAGS=0
But this shows the following error:
NMAKE : fatal error U1052: file 'makefile.mak' not found
?
Therefore I renamed "makefile" to "makefile.bak", but this only generated the following error:
makefile.mak(36) : fatal error U1033: syntax error : '=' expected
?
There are also several batch files on that same directory (such as windowsbuild.bat or windowsbuild_nmake.bat) that brought me nowhere.
?
@David Armour
I am having a look at VCPKG and let you know
?


Re: C++ IBKR API implementation and biddll.lib Intel Math Library

 

I use VCPKG and install the intelrdfpmathlib package.?

This is the simplest way if you are using Windows and Visual Studio.


Re: C++ IBKR API implementation and biddll.lib Intel Math Library

 

Have you try the instructions from file "Intel_lib_build.txt" in the TWS API source tree at source/CppClient?
?
On Mon, Jan 20, 2025 at 11:26 AM, Tradiator wrote:

Hi,
After I failed with the Purebasic network functions (could not go farther than connecting and getting current date/time...) I decided to use the C++ IBKR API implementation.
I am now stuck with things that are probably very simple for most of you ?;-(
?
Steps I made:
- Operating system: Windows 10 64-bit.
- Installed Microsoft Visual Studio 2022 for C++
- Reinstalled TWS API 10.30.01
- It appeared that "biddll.lib" the Intel "Decimal Floating-Point Math Library" was not found anywhere on my hard disk or anywhere else on the net.
- As I found out that I had to recompile that library, I installed "mingw64"
- After having waisted a lot of time with makes, nmakes, environment paths and many other things, no way to get past several errors (make mostly).
?
Do you know where I can find that "biddll.lib" (precompiled for Windows 64 bits preferably) ?
Or suggest simple steps in order to compile that damn library. Or find a work around.
I still do not understand why things have become so complicated since the past 20/25 years where dropping and OCX control on a VB6 form was so simple !
?
Thanking you in advance for your help
?


C++ IBKR API implementation and biddll.lib Intel Math Library

 

Hi,
After I failed with the Purebasic network functions (could not go farther than connecting and getting current date/time...) I decided to use the C++ IBKR API implementation.
I am now stuck with things that are probably very simple for most of you ?;-(
?
Steps I made:
- Operating system: Windows 10 64-bit.
- Installed Microsoft Visual Studio 2022 for C++
- Reinstalled TWS API 10.30.01
- It appeared that "biddll.lib" the Intel "Decimal Floating-Point Math Library" was not found anywhere on my hard disk or anywhere else on the net.
- As I found out that I had to recompile that library, I installed "mingw64"
- After having waisted a lot of time with makes, nmakes, environment paths and many other things, no way to get past several errors (make mostly).
?
Do you know where I can find that "biddll.lib" (precompiled for Windows 64 bits preferably) ?
Or suggest simple steps in order to compile that damn library. Or find a work around.
I still do not understand why things have become so complicated since the past 20/25 years where dropping and OCX control on a VB6 form was so simple !
?
Thanking you in advance for your help
?


How does a scanner with the Top % Gainers parameter in show % Change in pre-market?

 

Hi everyone, I know the TWS scanner with the 'Top % Gainers' parameter works outside regular trading hours. However, I¡¯m confused about how the % change is calculated for stocks during pre-market hours.
?
Specifically, does the % change compare the current pre-market price to the close price of the previous trading day, or does it compare the current pre-market price to the close price of the day before that?
?
For example: if it¡¯s Wednesday pre-market, is the % change based on the comparison of the current pre-market price of the stock and the stock¡¯s price at Tuesday¡¯s regular hours close, or is it compared to Monday¡¯s regular hours close?


Re: Delphi and TWS

 

?


Re: Strange Behavior After TWS Update on Old API

 

So you see them for sure in the "Trade History" window in TWS but you do not get them after you call ?
?
?
On Sat, Jan 18, 2025 at 11:52 AM, Adam S. wrote:

Yup, noticed that one and was able to work around it.? The one I couldn't figure out was only the execution termination message being sent without any execution info when I made an request for executions


Re: Strange Behavior After TWS Update on Old API

 

Yup, noticed that one and was able to work around it.? The one I couldn't figure out was only the execution termination message being sent without any execution info when I made an request for executions


Re: Strange Behavior After TWS Update on Old API

 

TWS version 10.30, and half of 10.31 has an error.? They sent an extra byte in the openorder message, when connected to a client of a version 10.29 or less.?? It was solved in 10.31i and later.


2FA with mobile AND old white card with numbers

 

Dear all,
?
For the authentication I'm using the old white code card.?
?
Now I have a gateway on a server. For that user I want to login by getting a push message on my mobile device. Now I have several questions
?
- Can I add my phone for 2FA WITHOUT loosing the option for my card with numbers?
- If so how can I do the registration of my phone (WITHOUT loosing the option of my card)
- How can I tell which account should use which 2FA (including paper trading users)?
?
I only want one use for the gateway to use the phone authentication. All other accounts and users the number on the card.