No it won’t object to that. (But why don’t you just try it yourself with your paper-trading account?)

?

But there IS a problem here: because current price is below the trigger price of that first order, it will be executed immediately – not what you want.

?

To fix this, use a ‘market if touched’ (MIT) order for the first one.

?

By the way, few members have much knowledge of the socket protocol, so when asking this sort of question it’s best to express it in terms of API calls.

?

Richard

You need to decide what your priorities are. If you just want a large challenge, by all means push ahead with PureBasic, but it will be difficult to say the least because you’ll be pretty much entirely on your own, working on a topic that you have no experience of. And for what benefit? ‘compact’, ‘efficient’, ‘no dependencies’ etc are simply irrelevant distractions.

?

But if you want to actually get something useful (for trading) working in the shortest possible time, then just forget about PureBasic.

?

If you’re already familiar with some form of Basic, then you could use Visual Basic .Net, which will cost you nothing if you use the free Community Edition of Microsoft Visual Studio: if you haven’t used Visual Studio before you’ll be blown away by its massive capabilities, and ‘free’ doesn’t mean ‘cut down’, it just means you can’t use it for commercial software.

?

Visual Basic .Net works perfectly well with IBKR’s C# API (as does any other .Net language). But it’s still a significant learning curve to make good use of the API, as it also is in other languages like Java.

?

But by far the fastest way to be productive is to use Python (and especially the ib-async API from , which is a third-party API implementation that makes life a lot simpler in many ways).

?

Don’t be fooled into thinking that Python, being interpreted rather than compiled, is a poor choice: for the kind of programs we write using the API, that difference is entirely irrelevant. While it’s true that a compiled API might get your order out of the door a couple of microseconds sooner than an interpreted one, that advantage is totally buried by the several milliseconds, or more likely several tens of milliseconds, that it takes for your order to reach the exchange.

?

By the way, I’m not a Python user (there was no Python API when I started on this back in 2003), but I’m very much aware of the considerable productivity benefits it offers. I’m just too hugely invested in more ‘traditional’ languages to make the switch.

?

If you decide to go the Visual Basic (or C#) route, I can provide you with a simple (but meaningful) sample program that shows how to get started. Actually I’ll link to it here – it’s a couple of years out of date and uses the 10.19 API version, but it still works fine:

?

?

You’ll find the executable in the bin/debug subfolder, so you can run it to see what it does. If you load the project into Visual Studio, you won’t be able to compile it without first updating the reference to the C# API.

?

I hope this isn’t all too confusing…

?

Richard

reqRealTimeBars is served by the historical data server. But IBKR does not maintain ‘last price’ historical data for forex pairs. So you will never get realtime bars for any forex pair, if you have WhatToShow=”TRADES”: you’ll just get this error message 420:

?

Invalid Real-time Query:No historical market data for EUR/CASH@FXSUBPIP Last 0

?

But if you set WhatToShow=”MIDPOINT”, it works fine:

?

20241203 09:49:47.068? id=131072 time=20241203-09:49:40 open=0.829655 high=0.829655 low=0.82962 close=0.82964 volume=-1 WAP=-1 count=-1

20241203 09:49:50.362? id=131072 time=20241203-09:49:45 open=0.82964 high=0.82968 low=0.82964 close=0.829665 volume=-1 WAP=-1 count=-1

20241203 09:49:55.533? id=131072 time=20241203-09:49:50 open=0.829665 high=0.829665 low=0.82962 close=0.82962 volume=-1 WAP=-1 count=-1

?

Richard

?