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

Can I just say that @Tradiator’s earlier post today has actually opened up a possibility to move forward with PureBasic. I’m in the middle of drafting a response to it that will indicate a way to proceed. It’ll be a while before I’m ready to post it though.

?

So if no-one objects, I’ll post that response here in due course (in case it might be useful for someone else in future), and I can then follow up privately with @Tradiator if he wants to try my suggestion.

?

闯ü谤驳别苍. If you’d rather I didn’t, let me know and I’ll just send it direct to him.

?

Richard

?

?

@TRadiator

?

This is in response to your post earlier today. Your statements are quoted in blue, followed by my replies.

?

“I am sorry to be a bit stubborn but I prefer to start in Purebasic. Might change later eventually.”

?

Well, all the advice you’ve received so far is DON’T. And that’s good advice. I think you should take it. Having said that, I’ll try to provide some responses to your statements that might help.

?

“However I am struggling using the TWSlib.dll. I can connect to this lib but I am having problems to calling a function.

What I would like to know is if TWSlib is the best option or is it better to use the windows socket solution ?

I am not sure but it seems that the source code suppplied with TWS API of the other languages use the socket version ?”

?

What do you mean when you say you can connect to TWSLib.dll? Do you mean you can reference the library, instantiate a TWS object and successfully call the eConnect() method? If so, that’s actually quite encouraging. If PureBasic can properly deal with ActiveX technology, then you should be able to use it quite successfully.

?

What do you mean by ‘the windows socket solution’? I presume you mean the CSharpAPI.dll library? ?Every API implementation, no matter what language, use a socket connection to communicate with TWS/Gateway: there is no other way to communicate. Every API sends the same message in response to an API call. The TWSLib.dll (also known as the ActiveX API) is basically just a wrapper around CSharpAPI.dll. This wrapper uses Microsoft’s ActiveX technology to enable it to be used in environments that ‘speak’ ActiveX, such as Excel and other Office apps, Delphi, even Visual Basic 6. This version of the API is in some respects easier to program with than the CSharpAPI.dll, but it also has quite a few ‘gotchas’ that make it rather confusing.

?

So assuming that PureBasic is a fully fledged ActiveX host, you should be able to use the full power of the API fairly straightforwardly, once you’ve got over the initial confusion.

?

The other day I sent you a link to two sample programs written in Visual Basic .Net and C#, both using the CSharpAPI. As it happens, I also have a version that uses the ActiveX API. It does exactly the same things as the other two, but uses TWSLib.dll rather than CSharpAPI.dll. I’ve now uploaded that sample to the same location (see the SimpleTWSActiveXDemo folder, or SimpleTWSActiveXDemo.zip which is easier to download):

?

().

?

Hopefully you’ll be able to use that code as a basis for something in PureBasic. I imagine the main differences will be in how you reference the project, the syntax for handling events, and of course the UI creation which would no doubt be quite an effort to port. I’d suggest starting with a much reduced version that has a button to connect/disconnect and handles the connectAck and errMsg events. Once that’s working you can build up with the reqMktData call and the tickPrice and tickSize events, etc.

?

I should add that this version is also not using the latest API, but it works perfectly well. It doesn’t include the change from Double type to Decimal type for sizes, but that won’t matter for the moment (unless you want to trade crypto-currency contracts). I’ll try to get round to bringing these samples up-to-date? at some point.

?

If you get stuck, email me privately (you can do this using the Reply to Sender facility). I’ll do what I can to help, but only if it looks like there’s a chance it can be made to work.

?

?

“And I also have the impression that the socket version is more generic and makes the program independent of changes made by IB to TWSlib.

What do you think ?”

?

No, not really. The ActiveX API provides pretty much exactly the same capabilities as the CSharpAPI.dll (I think there are a couple of things that IBKR haven’t been able to provide for technical reasons, but I can’t remember what they are without going and looking – certainly not things that you’re likely to need any time soon). Changes to TWSLib always affect the client program one way or another.

?

“Please help me, I really would like to start making TWSAPI calls and start working on the interesting part of the program.”

?

??????????????? I’ll try!...

?

?

Richard

?

Tradiator writes:

?

‘What has happened since then that interfacing to IB has become as difficult as climbing the Everest mountain!’

?

I think that’s a little unfair. If you use the ActiveX API, it’s still just as easy, except that you don’t host it on a form – thankfully, because that was never sensible. You just have to instantiate it like any other object with the New operator. Wiring up events in Visual Basic.Net is just as easy as it was in VB6, and more flexible. You can see all this in the ActiveX sample I linked to earlier.

?

The ActiveX API also has the benefit that events are fired on the main program thread, so that there is no need to be concerned with threading issues, and the UI can be accessed and modified directly. Though of course you can easily offload processing onto another thread where needed, and the async facilities in .Net make asynchronous working a delight.

?

It’s certainly true that it’s more complex when using the CSharp API. I think there were some bad design decisions back in 2015, and I was fairly vocal about them on the GitHub repository, but my arguments fell on deaf ears. But it’s all water under the bridge, and it’s really not that hard to get it going. Certainly not in the Everest league (I went trekking there in 1984, up to 18000 feet, just mindblowing…).

?

Richard