Global Configuration Not Loading about ibc HOT 10 CLOSED

I can't replicate this. It works fine for me with StoreSettingsOnServer=no.

Given that IBC plays no part whatsoever in storing TWS settings, I can't see that this can possibly be an IBC problem. The IbDir and StoreSettingsOnServer settings in config.ini are just passed straight through to TWS: IBC doesn't take any action on them at all.

I'm also confused by what you'vre written. You say you have 'no issues what so ever when running TWS manually', but you also say you have the problem when running the self-updating version, which can only be run manually. Can you clarify that?

from ibc.

A thought has just occurred to me.

If you're using the IbDir setting you MUST make sure you use an absolute path, and on Windows you MUST use double backslashes as the path separators. So for example:

IbDir=C:\\TwsSettings\\Live

not

IbDir=TwsSettings\\Live

If you don't stick to these rules, the results are rather unpredictable. Once again, this is just a result of the way that Java (and the command line interpreter) interact, and is beyond IBC's control.

I suppose it would be possible to put some checking in IBC to reject 'incorrect' paths, but the comments in config.ini make it perfectly clear what the rule is and it's very rare that anyone gets this wrong.

from ibc.

Yes you are right about the self updating version, I mean just 972 and 976. I'm not attempting to run IBC with the self-updating version, sorry for the confusion. The problem does not occur when running 972, 976 or the self-updating version manually.

I used the aboslute path for the IbDir setting as documented in config.ini.

I have had this problem on the 3/3 computers I've run it on.
I wonder if there's any more information you're missing to re-create the error?
Im running windows IBC and TWS from Ubuntu (WSL).
This is the command I use from within ubuntu:
cmd.exe \c /mnt/c/home/source/python/prog/ibmanager/IBC/Scripts/StartIBC.bat 972 /IbcPath:C:\home\source\python\prog\ibmanager\IBC /Config:C:\home\source\python\prog\ibmanager\IBC\Accounts\config.ini

When I run IBC TWS fetches settings from the server. It does this whether StoreSettingsOnServer is 'yes" or "no". The settings that are fetched from server are saved in tws.tmp. I can see from this file that allowPreciseFXTrading="false", always immediately after load. I then check the "Allow Forex trading in 1/10 pips" box. When closing TWS a popup says "Saving Settings" followed by "Uploading Settings", but this particular setting is never actually uploaded to server. It is however saved to tws.xml because I see in this file allowPreciseFXTrading="true". This happens whether StoreSettingsOnServer is "yes" or "no".

I'd like to set IBC to use local settings just like when running TWS manually and unchecking "Use/store settings on server" at the login screen. In this case TWS uses settings stored locally. How do I achieve this with IBC?

from ibc.

You say you're 'running windows IBC and TWS from Ubuntu (WSL)': this is a total bombshell! You didn't think to mention this before? What gave you the idea that this is in any way a supported configuration?

Until now I have never seriously tried to run TWS/Gateway or IBC in WSL. Actually I did try running the IBC bash scripts shortly after WSL was first made available, but they failed, so I thought I'd just leave it till WSL was more mature. It certainly is very much more mature now, and is an impressive piece of work (and will be even better, presumably, when it moves to using the new Microsoft Linux kernel in the foreseeable future).

So perhaps it's time to take a closer look at all this, but I'm reluctant to commit the necessary time to it unless I see a real need for it. Perhaps you can explain what benefit you think this will bring? Why not just run it on Windows? And can you clarify whether you're actually trying to run IBC and TWS within the WSL environment, or just somehow initiate them from WSL but have them actually running within Windows: from what you've written, it sounds like the latter, in which case, I don't really see the point.

Also, can you tell me why you're calling StartIBC.bat directly instead of using the higher level scripts? They are much better because they give so much more diagnostic information. I can't tell anything from what you've said so far.

I'm just installing the current WSL on this machine and will give it a whirl later, but first it needs to be restarted, and also I have to go and do other things.

Any more information you can give me would be appreciated.

from ibc.

Ok, I've tested running IBC from WSL (using the top-level .bat files), and I'm glad to say it all works fine. Though I'm still keen to know why you think this might be useful.

[Running the Bash scripts in WSL and getting GUI output from TWS/Gateway to an X Server running on Windows is a different matter, and one that can wait until I've nothing better to do.]

Regarding the problem with not being able to store the settings locally only, I realised this evening that there is indeed a bug in IBC such that if you once set StoreSettingsOnServer=yes in config.ini, that setting will remain for ever more regardless of what it says in config.ini.

I'll fix that shortly (not tonight though).

To work around this, make sure IBC is not running, then look for a file called jts.ini in your TWS settings folder: by default this is C:\Jts, but you can override this with the IbDir setting in config.ini). Open this in a text editor, and you'll see a line that says:

useRemoteSettings=true

Change this to:

useRemoteSettings=false

Save the file and start IBC again and all should be well.

from ibc.

From WSL I am calling cmd.exe so Im effectively still running in a regular windows environment. I've also run it from windows command promt with the same results. I believe the two commands below to be equivalent so I don't see why how I'm running from WSL to be an issue. I'm running it like this because I have some more complicated logic on top of IBC. My program which wraps IBC manages mulitple accounts (config1.ini, config2.ini ... ) pings the ports that TWS listens on, kills IBC at certain times and restarts. All this extra functionality was easier to accomplish in a linux environment, but all my programs run in windows hence the blend of the two systems.

From WSL: ("initiate them from WSL but have them actually running within Windows")
cmd.exe \c /mnt/c/home/source/python/prog/ibmanager/IBC/Scripts/StartIBC.bat 972 /IbcPath:C:\home\source\python\prog\ibmanager\IBC /Config:C:\home\source\python\prog\ibmanager\IBC\Accounts\config.ini

From command prompt:
C:\Users\Emil>C:\Jts\ibmanager\IBC\Scripts\StartIBC.bat 972 /IbcPath:C:\Jts\ibmanager\IBC /Config:C:\Jts\ibmanager\IBC\Accounts\config.ini

Is the setting useRemoteSettings=false supposed to uncheck the box "Use/store settings on server" at the login screen because it does not for me. Everytime I run TWS manually or with IBC I see that "Use/store settings on server" is checked regarless of whether useRemoteSettings=false or useRemoteSettings=true.

What exactly is the effect of StoreSettingsOnServer=yes, how does IBC manipulate TWS to achieve this?

from ibc.

I have discoverd the problem. It is caused by setting OverrideTwsAPIPort in config.ini. To reproduce:

0. Using default settings for IBC-3.7.5 and TWS 972.
1. Run StartTWS.bat. Once TWS is running tick File/Global Configuration/Display/Ticker Row/"Allow Forex trading in 1/10 pips".
2. Close TWS and IBC.
3. In config.ini set OverrideTwsApiPort to some value.
4. Run StartTWS.bat.
   Once TWS is running you will find that "Allow Forex trading in 1/10 pips" is unchecked again.

My hypothesis is that IBC sets the TWS API socket port before the normal TWS settings loading procedure is completed and causes it to be interrupted. If this is the case then adding a delay here would solve it.

from ibc.

First, just let me say that the comment I made last night about a bug in IBC was too hasty: I had a cursory glance at the code, and thought it was wrong, but it does actually do what was intended.

However there IS a bug, but it's a bit more nuanced than I expected. When TWS creates the Login dialog, it sets the Use/store settings on server checkbox according to the useRemoteSettings value in jts.ini. Then, when IBC detects the Login dialog, it in turn sets the 'Use/store settings on server' checkbox as specified in StoreSettingsOnServer in config.ini, which I naively thought would give the desired result.

However, IBC does this before setting the username and password, and what I hadn't appreciated until this morning is that when the username is set, TWS sets the checkbox again according to the latest value stored in the settings for that user, thus overwriting whatever value IBC had set.

You can easily check all this out by clearing the username from config.ini and then running IBC, so that TWS waits on the Login screen for you to manually enter the username: as soon as you do, you'll see the checkbox change if the previous session differed from what's in config.ini now.

Fixing this might be a little tricky: it's not just a case of changing IBC to insert the username before setting the checkbox, because not specifying the username in config.ini is a perfectly valid configuration. So IBC mustn't set the checkbox until after the username has been set by whatever means. Probably I'll have to attach a listener to the login button, and intercept the click event to set the checkbox before TWS processes the click.

Thanks for your description of how you're using WSL. It's always useful to get an insight into the ways in which people are using one's software, as this often opens up new vistas.

And thanks for your observation regarding the effect of OverrideTwsApiPort: that is very helpful. I've reproduced your finding, but I need to investigate this a bit more deeply to understand it, and then determine the best way to fix it. Just adding a delay is rather a blunt instrument, though it may come to that in the end.

from ibc.

@emilbigaj Just a quick update.

I've fixed the problem with the StoreSettingsOnServer setting. If you like, I can let you have a beta version, or you can wait for the official release.

By the way, I should have said before that the best workaround for that problem is simply to run TWS manually, enter your username and password, set the Settings directory field, and clear the Use/store settings on server checkbox. Then complete the login, and shut down TWS. Now make sure StoreSettingsOnServer=no in config.ini, and all should be well.

The problem with Allow Forex trading in 1/10 pips checkbox is turning out to be very strange. Delaying processing the OverrideTwsApiPort setting makes no difference, and in fact I've now proven that when IBC accesses the global configuration dialog, the checkbox is in fact correctly set, both before and after IBC sets the API port. So TWS is correctly loading the value from its settings before IBC ever comes near the dialog. However when IBC 'clicks' the OK button after setting the API port, TWS seems to magically forget the checkbox setting.

So I wondered whether this is maybe nothing to do with IBC at all, and it turns out that that's correct! Try it yourself: run TWS manually, set the Allow Forex trading in 1/10 pips checkbox, and shutdown TWS. Now run it again, confirm the checkbox is still set, then change the API port setting, click OK, and accept the API change confirmation. Display the config dialog again, and you'll see that the checkbox has been cleared.

I want to do more experimentation to see whether it's only changing the API port that has this effect, or any API setting, or any other setting.

I'd be grateful if you can confirm this, and let me know of anything else you notice.

But at the moment it's certainly looking to me like a bug in TWS.

from ibc.

I've done a bit more experimenting, and what I've found is that it's not necessary to make any configuration changes at all: just opening the API Settings page in the Global Configuration dialog and then closing the dialog is enough to reset the Allow Forex trading in 1/10 pips checkbox.

I'll leave you with the happy task of reporting this bug to IB if it's causing you a problem.

from ibc.