Newbie Looking for VB.NET program using new 9.72 API

M

Miles..Den

I have a working trading program for 20 years, but each new API version throws me into a tailspin. I use ActiveX so far, but wanting to get set up with VB.NET and the new 9.72 API. (Will also take ActiveX under the 9.72 API if that is possible)

I can see demise of ActiveX on the horizon so want to get ahead of it if possible.

All I want is a small program that does nothing but connect to the TWS so I can see
the events, and begin modifying my code to work thru the new API.

Face page of this website says there is a VB program in the 'files' section??
 
I am actually looking for a small program illustrating how to utilize the new IB 9.72 API in a vb.net program to interface IB TWS.

Just wondering if anyone has actually made this work with VB.NET. It is no longer listed
among the languages, but one of their web casts says that EVERY API version supports prior
versions.
 
I think ActiveX will hang around. 973 API has an Excel demo using it. IB went to the trouble of converting whatever they had in that old Tws.ocx file (source code never released) into a C# version. What IB didn't do is demonstrate how to use the C# dll ActiveX in a C# or vb.net sample. You have to register the dll with regasm, not regsvr. Regasm is found in the Windows\Microsoft.Net\Framework\4.xxxx directory (from memory) and you have to regasm.exe the dll file in an elevated shell ( cmd window that's been opened with Administrator rights...google regasm, you'll see how).

I too am in the process of updating some old (C#) code which relied on the old Tws.ocx. I think it's going to be as simple as Referencing the ActiveX dll (Twslib.dll) in a VS Solution, put "#using Twslib" statements in files and then I think I do something like this:

Tws tws = new Tws(); // use tws for hooking up event callbacks..i.e. "+=" / "-="
var itws = (ITws) tws; // reference itws, not the tws for creating objects, making IB requests

It's ActiveX so each Tws you instantiate (most apps need only 1) has to be associated with a Windows Form for the message routing, right? It can be a non-visible Form used only for the purpose of association with the Form's Windows message queue.

I guess I'll get my trial by fire too when I get to hooking up the IB functions for my app.

Yes, I can convert the app to use their newer EWrapper interface using sockets but I still wantvto know how everything works with the C# ActiveX dll first.

One of the great joys in my trading, when in need of custom programming, is that I don't have to wish I had decades of formal programming with an advanced degree in Computer Science!! Funny how one past "life" became so useful to the next.

Anyway, I don't know vb.net syntax. When you come from a long history of C/C++/Java, C# feels natural, vb.net looks completely alien, even having lightly coded with the old VB6 ages ago.

[On a totally unrelated note, learn how to program in Clojure. For non-GUI programming / multi-threaded environments, it's a TOTAL THRILL to have non-mutable data structures and software transactional memory (STM) built-in. NOBODY ON THIS PLANET SHOULD HAVE TO FACE MANUAL LOCKING PROBLEMS...STONE COLD EXPERTS CAN'T GET IT RIGHT EITHER...object-oriented programming solves nothing in this area]
 
Last edited:
SteveH said:
I think ActiveX will hang around. 973 API has an Excel demo using it. IB went to the trouble of converting whatever they had in that old Tws.ocx file (source code never released) into a C# version. What IB didn't do is demonstrate how to use the C# dll ActiveX in a C# or vb.net sample. You have to register the dll with regasm, not regsvr. Regasm is found in the Windows\Microsoft.Net\Framework\4.xxxx directory (from memory) and you have to regasm.exe the dll file in an elevated shell ( cmd window that's been opened with Administrator rights...google regasm, you'll see how).

I too am in the process of updating some old (C#) code which relied on the old Tws.ocx. I think it's going to be as simple as Referencing the ActiveX dll (Twslib.dll) in a VS Solution, put "#using Twslib" statements in files and then I think I do something like this:

Tws tws = new Tws(); // use tws for hooking up event callbacks..i.e. "+=" / "-="
var itws = (ITws) tws; // reference itws, not the tws for creating objects, making IB requests

It's ActiveX so each Tws you instantiate (most apps need only 1) has to be associated with a Windows Form for the message routing, right? It can be a non-visible Form used only for the purpose of association with the Form's Windows message queue.

I guess I'll get my trial by fire too when I get to hooking up the IB functions for my app.

Yes, I can convert the app to use their newer EWrapper interface using sockets but I still wantvto know how everything works with the C# ActiveX dll first.

One of the great joys in my trading, when in need of custom programming, is that I don't have to wish I had decades of formal programming with an advanced degree in Computer Science!! Funny how one past "life" became so useful to the next.

Anyway, I don't know vb.net syntax. When you come from a long history of C/C++/Java, C# feels natural, vb.net looks completely alien, even having lightly coded with the old VB6 ages ago.

[On a totally unrelated note, learn how to program in Clojure. For non-GUI programming / multi-threaded environments, it's a TOTAL THRILL to have non-mutable data structures and software transactional memory (STM) built-in. NOBODY ON THIS PLANET SHOULD HAVE TO FACE MANUAL LOCKING PROBLEMS...STONE COLD EXPERTS CAN'T GET IT RIGHT EITHER...object-oriented programming solves nothing in this area]
More...
 
Following is an email response I received from IB after asking questions:
--------------------

In response to the inquiry, using the C#.NET API with a VB.NET program is very similar to using a C# program from an API point-of-view. All the function calls are the same with the same number of parameters, and only the syntax differs slightly. Since our webinars focus on the API itself and not application development, I don't think an additional webinar just for VB.NET would provide much in addition, but instead I think it's best to mention VB.NET compatibility within the context of the webinar on the C#/.NET API.

VB.NET is not deprecated, it's just that typically we suggest using the VB.NET directly with the C#/.NET API instead of using ActiveX, as ActiveX creates an additional layer and can introduce some additional complications. With Excel its necessary to use ActiveX so this isn't an option the same way.

The APIs were developed with Visual Studio 2012 and so this is the minimum version needed for compatibility. The ActiveX API was rewritten in C# starting in version 9.72 and now is named TWSLib.dll instead of Tws.ocx.
----------------
All of this seems to indicate to me that VB.Net should still work with the 9.72 API. I cannot
even get 9.72 to load and register properly( guess those are the correct terms), and then they comment that I need a newer version of Visual Studio. Isn't a dll a compiled file that I should not have to touch unless I want to modify it?

Anyway, I would like to find someone that has actually been successful utilizing the 9.72 with VB.NET.

I have many hours invested in my program, so hesitant to start over. I actually programmed in C and C++ years ago, and could make technical programs work, but found it really tough in terms of the visual display components and linking them to code.
 
What the IB rep didn't say about ActiveX was this:

It's an STA (Single Threaded Apartment) model. In simpler terms, all the events coming from the IB ActiveX dll are GUARANTEED to be placed onto the GUI thread so you don't have to do all of that "if (this.InvokeRequired)..." code bloat mess to marshal over the GUI updates from a background thread to the GUI thread. In my book, ActiveX is less complicated in this regard.

I'd stay away from C/C++ for Windows GUI. Stick with Visual Studio Windows Forms if you can. It is soooo easy by comparison to anything else. XAML / WPF was supposed to be great...great for whom? No surprise things got awfully quiet after v4.5. Well, uh, XAML is great, yeah, that's it. (imo, XML sucks and anything based on it...total PITA to work with).

Work my code snippet back into VB.NET. Create a new TWS class, put that in a variable and then cast that variable into the class interface to TWS (I *think* they call that ITws. ALL the goodies to talk to the new ActiveX API are by accessing the ITws interface. That interface has already been implemented by IB.

Miles, you gotta give to get sometimes. You can't be clueless after 20 years of programming and what I have said. You're the VB.NET guru, you tell me why this is so hard when, really, it looks pretty straightforward having looked at the Twslib ActiveX code (no, you don't have to learn C#, just translate a couple of lines of it).
 
You must log in or register to reply here.
Back
Top