Recognise IB Gateway 1037+ login controls (hyphenated forms)

[frankboehkeenlab]

Problem

IB Gateway 10.37 renamed several UI controls to use hyphens instead of spaces. IBC 3.23.0 doesn't recognise the new forms, so GatewayLoginFrameHandler.recogniseWindow() returns false, the login handler never fires, and IBC eventually exits with code 1112 (LOGIN_DIALOG_DISPLAY_TIMED_OUT).

Diagnostic signature in the IBC log:

IBC: detected frame entitled: IBKR-Gateway; event=Opened
... (60s of silence — no 'Setting user name', no click attempt)
IBC: Exiting with exit code=1112
Check for login dialog display timeout

Affected controls

Confirmed by enabling LogComponents=open and dumping the live Swing tree of Gateway 10.37.1q's login window:

Element	Old (still works)	New (Gateway 1037+)
Window title	IBKR Gateway	IBKR-Gateway
Login button	Paper Log In	Paper-Login
Mode toggles	Live Trading / Paper Trading	Live-Trading / Paper-Trading
API toggle	FIX CTCI	FIX-CTCI

Fix

Purely additive — keep the existing strings, add the new ones as fallbacks. Touches three files:

• GatewayLoginFrameHandler — title + paper-login button + FIX-CTCI toggle
• AbstractLoginHandler — generic findLoginButton + setTradingMode toggles
• ReconnectDataOrAccountConfirmationDialogHandler — title

Older Gateway/TWS versions remain matched by the existing space-separated strings.

Verification

End-to-end test on Gateway 10.37.1q (Windows, paper trading, German locale):

• Kill all Gateway/IBC processes
• Fire StartGateway.bat
• t+10s: IBC log shows in order — Setting user name → Setting password → Login attempt → Authentifizierung... → port 4002 LISTENING
• Held LISTENING continuously for 2 minutes, same Java PID, no drops

Before the patch: every IBC start exited 1112 after exactly 60s; after the patch: full auto-login completes in ~10s.

[rlktradewright]

I never downloaded 10.37.1q, and it's no longer accessible from the IBKR website, so I'm unable to verify this. I'm not suggesting your report is incorrect, just that I can't verify it.

However it is no longer the current stable version (and hasn't been for some time). I suspect this is one of those occasional mistakes that IBKR make, and because it's no longer current they haven't bothered to fix it.

The current version is now 10.45.1g. That version doesnt suffer from this problem.

Is there some reason why you can't just upgrade to the current stable version? I'd rather not have to go to the trouble of releasing a new version of IBC so that an unsuported old version of Gateway with a fault can be made to work.

[frankboehkeenlab]

Thanks for the response — I upgraded to 10.45.1g as suggested and the bug reproduces identically. The cause turns out to be locale-specific, which explains why you don't see it:

Element	English locale	German locale (OS = de_DE)
Window title	IB Gateway	IBKR-Gateway
Login button	Paper Log In	Paper-Login
Mode toggles	Live Trading / Paper Trading	Live-Trading / Paper-Trading
API toggle	FIX CTCI	FIX-CTCI

The hyphenated forms are IBKR's German UI strings. They've been emitted by Gateway since at least 10.37 and are still present in 10.45.1g (verified by freshly installing the current stable and dumping the live Swing tree with LogComponents=open):

2026-06-17 13:14:24 IBC: Window structure for frame entitled: IBKR-Gateway; event=Opened
|   |   |   null(javax.swing.JLabel){JLabel: IBKR-Gateway}
|   |   |   |   |   null(javax.swing.JButton){JButton: Deutsch}
|   |   |   |   |   |   |   null(twslaunch.jtscomponents.V){JToggleButton: FIX-CTCI}
|   |   |   |   |   |   |   null(twslaunch.jtscomponents.V){JToggleButton: IB API}
|   |   |   |   |   |   null(javax.swing.JLabel){JLabel: Trading-Modus}
|   |   |   |   |   |   |   null(twslaunch.jtscomponents.V){JToggleButton: Live-Trading}
|   |   |   |   |   |   |   null(twslaunch.jtscomponents.V){JToggleButton: Paper-Trading}
|   |   |   |   |   |   |   null(javax.swing.JButton){[Disabled]JButton: Paper-Login}

Stock IBC 3.23.0 against this Gateway exits 1112 after 60s of silence post-frame Opened, identical signature to the 10.37 report. The patched build auto-logs in successfully in ~10s, on both 10.37 and 10.45.

So this isn't an obsolete-Gateway bug — it's an IBC i18n gap that's been hiding under English-locale testing. Setting [Logon]/Locale=en in jts.ini is ignored: Gateway 1037+ respects the OS locale, not the jts setting (native.encoding = Cp1252, language/country is de_DE shown in the installer log).

Happy to add other-locale checks if you can point me at known label variants for FR/IT/JP, but the German fix alone already unblocks non-English users on every Gateway 10.37–10.45 build.

[rlktradewright]

Ah, yes, Gateway and TWS have aways been multilingual.

But IBC (and its predecessor IBController) have always been English only. This is mentioned in the User Guide.

So the workaround for this is to run TWS/Gateway in English rather than your locale. I realise this could be a problem for some users, but it presumably won't be for you.

The various language strings needed to internationalise it are programmatically available to it, but it's not a 5-minute job and I have no intention of doing it at this stage..

[frankboehkeenlab]

fair point, understood and agree :)

[bsdice]

Like your patch, added it to my local repository. Even though I run TWS in en_DE locale and english IBC/TWS:

$ localectl
System Locale: LANG=en_DE.UTF-8
               LC_CTYPE=en_US.UTF-8
    VC Keymap: us-altgr-intl-nodeadkeys
   X11 Layout: eu

That is US keyboard with EurKEY layout, english language and collation, but monetary, paper sizes, address format, telephone, measurements, and numerics are german, week starts on Monday. With date in ISO-format:

$ date
2026-06-17 W25.3 14:19:00 +0200 CEST

Which TWS JRE translates into:

$ ./java -XshowSettings:properties -version 2>&1 | grep -iE 'user.(country|language|format|variant)'
user.country = DE
user.country.format = US
user.language = en

Look for a file called locales.jar if you want to go mad translating labels. But I caution, save the time. After many years you are the first to even complain about i18n. If you have any issue with TWS or Gateway, you will find nothing using german translations.

There is a property called locale_to_use, could be enough to switch to en_US without switching the OS. Like -Dlocale_to_use=en_US or similar.

Any reason you'd want to stay with German locale?

[frankboehkeenlab]

I've already decided to change back to english, just wanted the heads up of my findings.