Test Programs

The following programs are currently available:

IBvTradeBuild	demonstrates that IB's ActiveX control is event-driven from the socket, rather than periodically polling the socket
TWSActiveXTester	demonstrates that you cannot miss events from the ActiveX control just by taking a long time to process them
TWSDemo Spreadsheet	demonstrates how to use the ActiveX control in an Excel spreadsheet
SimpleTWSDemo	a VB6 program that records tick events to files. Used in conjunction with and extended version of the TWSDemo spreadsheet to show that heavy processing in Excel will not cause events to be missed

NB: I may not get round to  upgrading these programs as TradeBuild and the IB ActiveX control develop. So you might need to tweak them to get them to compile. If you can't make them work, contact me at info@tradewright.com and I'll fix them.

You must of course install a recent version of the IB ActiveX control before compiling and running these programs. Don't forget to run TWS and login before running these programs.

IBvTradeBuild

[NB: to compile and run this program, you must first install the TradeBuild COM component, which provides a socket based, object-oriented interface to TWS. For details of TradeBuild, click here (don't worry, it doesn't cost anything!).]

This program demonstrates that the IB ActiveX control is event driven from the socket, and does not periodically poll the socket as some people assert.

It uses both the IB ActiveX control and TradeBuild to connect simultaneously to TWS, then requests market data on both connections. For each market data event received from TradeBuild and the ActiveX, it generates an accurate timestamp (using TradeBuild's getTimestamp function), and records details of the event in a large table. When the table is full (it has 10000 entries) or when you close the form, it writes out all the table entries to a text file called IBvTradeBuild.log, which is located in the folder that the program runs in.

After running the program for a while, open the IBvTradeBuild.log file in Notepad, and browse through it. The first field on each line is a timestamp formatted yyyymmddhhmmss.zzz, where .zzz is millseconds. You'll notice that after the first few seconds (when TradeBuild and the ActiveX are starting up their dialogue with TWS), the events from the ActiveX and TradeBuild are exactly in step, and the timestamps are identical (occasionally there is a difference of a few milliseconds - this is probably because Windows has grabbed the processor to run another process). By the way, TradeBuild generates bid, ask and trade events containing both the price and the size, not separate price and size events like the ActiveX control.

TWSActiveXTester

This program demonstrates that no matter how long it takes to process an event, the IB ActiveX control will not lose or discard events.

It connects to TWS via the ActiveX control, and requests market data. For some events received, it simulates lengthy processing by looping for a length of time governed by the value in the Processing Time field on the form. Every tick price and tick size event received is written to a file called TWSActiveXTest(n).log, where n is the value of Processing Time.

Compile the program. Then run two copies of the .exe file. In one, set Processing Time to 0, and in the other set it to some other value (say 5, representing 5 seconds of processing time for some events).

Click the start button on both forms. Once they've connected to TWS, they'll start to write events received to a space on the form, so you can see something's happening. You'll also be able to see when the 'lengthy processing' is happening.

After a while, click the stop button (this can be a bit tricky on the lengthy processing one), and close the programs. Now compare the log files: you'll see that exactly the same events are logged in both (but of course the timestamps in the lengthy processing one will show where their delivery has been delayed). Even if you increase the processing time to 60 seconds, the ActiveX control will still deliver the events correctly.

By the way, it is NOT valid to simulate lengthy processing by setting a break point in one of the event procedures, and then resuming after a period. If you do this, you will find that some events are not logged. This is a result of the way that Visual Basic itself behaves in certain circumstances. When VB enters break mode, or the application displays a message box, VB discards any events received from controls until the condition has changed. This is because there is no possibility of the application handling them. Rather than VB queueing events received in such conditions (which would be impractical, because the condition could persist for an indeterminate period), VB lets the control decide what to do by calling a standard COM interface called IOleControl::FreezeEvents. The control should then decide whether it should discard events or queue them up to be fired when the freeze is lifted. In the case of the IB ActiveX control, it looks as though it continues to read the data from the socket, but either just discards it or notifies the relevant events anyway (in which case VB will ignore them).

It would be possible therefore for IB to modify their ActiveX control so that when VB notifies a freeze, it either stops reading data from the socket or it queues important events like orderStatus, execDetails etc and then fires them when the freeze is lifted, discarding less important events. The difficulty is that, because the application may be receiving up to 100 market data streams, and 3 market depth streams, there can be a considerable amount of data coming through the socket. If it doesn't read the data from the socket, eventually the socket buffers will overflow and the socket will break (from my own testing of my TradeBuild socket-based component, I know that this happens when the amount of data buffered is something in excess of 100Kbyes). If it does read the data, and stores up important events for firing when the freeze is lifted, it has to find space for them all, so at some point it would have to start discarding events. Neither of these outcomes are helpful to the client program.

Therefore I believe that IB are correct in their current handling of event freezes. The guideline to API users must be, never use the msgBox function while the ActiveX control is connected to TWS.

TWSDemo Spreadsheet

Please note that to run this spreadsheet you will also have to install IB's TWS API components, which you can download from their website.

As I rarely do any work on this demo, it may well not function with the latest IB API version (because IB sometimes make incompatible changes to their API components) . Usually it just requires some minor editing to make it work, but if you have any problems please email me at info@tradewright.com. The current version works with API 9.51.

This spreadsheet demonstrates how to use the IB ActiveX control in an Excel spreadsheet - more importantly, it shows that contrary to some opinion, it does actually work in Excel!

It doesn't exercise every API capability, but enables you to open up to 40 tickers, and to place, modify and cancel orders. The tickers sheet also shows the open, high, low, close and volume for the current 5-minute bar for each ticker.

You must have TWS running and configured for API clients before you start the spreadsheet.

You can specify a set of predefined tickers in the predef.txt file that resides in the same folder as the spreadsheet. Clicking on the Add predefined tickers button starts all the tickers defined in this file. Note that the predef.txt file included in the download has a number of predefined tickers that you will probably want to edit (in particular they may be expired contracts by the time you download it).

If you want to test placing orders, try using it with the IB demo system (ie logon to TWS with username set to edemo and password set to demouser), or better still, with your IB paper trading account.

Please note that there is a deficiency in Excel that rather reduces the usefulness of an ActiveX-based approach. This is that when the user is editing a worksheet cell, Excel discards any events fired by any ActiveX controls. This means that, for example, order status and fill events may be missed. This is why this spreadsheet uses form fields rather than cells for entering ticker and order details, since typing in them does not stop events.

Note: if you have macro security set to High in Excel, you won't be able to run this spreadsheet. Setting macro security to Medium will enable it to work. To do this, click on Tools, Macro, Security and set the security level to Medium, then open the spreadsheet.

DO NOT set the security level to Low, as this will enable any macro in any spreadsheet to run, which potentially leaves you vulnerable to harmful worms and viruses in spreadsheets you receive as email attachments or from elsewhere.

Disclaimer: this is not a polished product, and is certainly not intended to be used for live trading! It was developed in a short time just to demonstrate how to do it. It does not conform to the professional design and coding standards that I normally employ in a genuine product. You use it entirely at your own risk, and any losses or damage incurred are your own responsibility.

Testing the ActiveX Control in Excel

SimpleTWSDemo is a VB6 program that requests market data for the securities defined in the predef.txt file, and writes tickprice and ticksize events for each of these securities to a separate file (in the folder that SimpleTWSDemo is loaded from).

The purpose of this is to run it in parallel with the ExtendedTWSDemo spreadsheet while the latter is in 'hard work' mode - this means that most of the time the spreadsheet is executing VB code so that tick events cannot fire. You can then compare the tick files produced by SimpleTWSDemo with those produced by the ExtendedTWSDemo spreadsheet, and you'll see that the events recorded are identical in both, though the spreadsheet ones will eventually be lagging far behind during busy market periods (unless your computer is very fast).

In other words, the fact that Excel is busy running VBA code does NOT mean that events from the TWS ActiveX control are missed. They are just queued until Excel is able to handle them.

To make the ExtendedTWSDemo spreadsheet log tick events to files, just set the 'Log ticks to file' checkbox BEFORE starting the tickers.

To start the tickers defined in the predef.txt file in the ExtendedTWSDemo spreadsheet, click on the 'Start predefined tickers' button in the top right corner.

To make the TWSDemo spreadsheet run in 'hard work' mode, just set the 'Work hard' check box, and choose whether to use the intensive VBA or intensive calculation mode. You can do this after the tickers are started, if you want to make sure they're all running properly first. Note that when it's in VBA hard work mode, Excel may only respond very slowly to the user interface because it may build up a backlog of tick events to process (depending on the tickers running and the speed of your computer): in this case you might want to kill Excel from the Task manager.

By the way, it's best not to run this spreadsheet while the Visual Basic Editor is open: that makes it run very slowly!

The download includes the source code for SimpleTWSDemo and the ExtendedTWSDemo spreadsheet. It also includes the compiled SimpleTWSDemo.exe, in case you don't want to build it yourself.