Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
ActiveX in API version 9.72 and later
|
In message #34389 Richard King wrote:? ...it’s a .Net component that uses COM Interop to expose the same interfaces to COM clients (eg VB6, Excel, Delphi) as the previous versions (which were native C++ COM code).
I have 9.73 installed, and I am not seeing any sample programs (except maybe Excel) that use the ActiveX.? Am I missing something?? Has anybody been able to connect to the C# version ActiveX (version 9.72 or later) using a language with a COM interface other than the ones having a sample (i.e. C++, C#, Java, Python, VB.Net)?? I don't know how to tell if the ActiveX even works, much less how to access it. [rwk] |
|
On Tue, Oct 3, 2017 at 08:46 am, Richard Seguin wrote:
I might be wrong, but I think there's no more ActiveX with TWS version 9.72 and up.I too seem to recall reading that.? Versions 9.72 and later have a dotDLL that is considered an ActiveX.? What is missing is the dotOCX that I think included a typelib.? How this all works "under the hood" is a bit beyond me, as I am an app programmer, not a software engineer.? It's not clear to me that we can use API 9.72 with VB6, Matlab, Delphi, etc "out of the box" without doing some rebuilding.? That's what I am asking.? I was hoping to keep using Delphi, but I was unable to get even the latest version working with help from pre-sales tech support from the Delphi vendor. |
|
ActiveX available in 9.72+, its just de-emphasized as compared to the .NET component, so the Excel spreadsheet is the only sample included which uses ActiveX. The ActiveX dll is now written in C# and installed to:
C:\TWS API\source\CSharpClient\activex\bin\Release\TWSLib.dll The type library is at: C:\TWS API\source\CSharpClient\activex\bin\Release\TWSLib.tlb The compiled control provided is only compatible with 32 bit applications, but that should change very soon. |
|
Thanks Josh.? I had pretty well concluded that Excel was the only sample that now works with the ActiveX.? Apparently, IB has pulled the plug on older technologies such as VB6, Matlab, Foxpro, Delphi, etc.? I see there is another dotDLL registered:? C:\Windows\SysWOW64\TwsSocketClient.dll
I installed the latest version (10.2 Tokyo) of Delphi and tried to import the ActiveX.? It sees an ActiveX, but I'm not clear which dotDLL it is.? And when I try to import, it tells me the typelib is missing.? I am guessing I could somehow massage the dotTLB file to make the import work, but I had already wasted enough time on it, and I want something more straightforward. My ultimate motivation for this is the fear of another dreaded forced upgrade.? It hasn't happened very often, but if it did now, I would have to quit trading while I learn another programming language and re-program my system. |
|
Nick
I seem to remember someone offering a Delphi component for the TWS Api. I think it might have been around $100 but that's probably less than the total time and aggravation for moving to a new platform.
toggle quoted message
Show quoted text
The info might be here www.hhssoftware.com/iabsocketapi/index.html On 10/3/2017 1:45 PM, rwk wrote:
My ultimate motivation for this is the fear of another dreaded forced upgrade.? It hasn't happened very often, but if it did now, I would have to quit trading while I learn another programming language and re-program my system. |
|
On Tue, Oct 3, 2017 at 11:06 am, Nick wrote:
I seem to remember someone offering a Delphi component for the TWS Api.That's Ross Hemingway's product, and it's still available.? I used it in the past, but I switched to the ActiveX because the latter is or WAS supported by IB.? A product supported by the broker seemed more secure. I remembered the IABSocket component after my original post on this tread, and it is my probably my best fallback in the event of a forced upgrade.? I would still prefer an IB-supported product, if I don't have to jump through a bunch of hoops. |
开云体育I’m not sure what you’re having difficulty with here. ? 9.72 and later still contain a perfectly functional ActiveX control, that works fine with VB6, Excel, and no doubt all the other COM-capable platforms like Delphi. I just dusted off an ActiveX performance testing program written ages ago in VB6, and it works perfectly with 9.72 after bringing the various changed API calls up-to-date. ? Rather than being a single .ocx file as in the ‘old days’, there are two files in C:\TWS_API\source\CSharpClient\activex\bin\Release, namely ? TWSLib.dll and TWSLib.tlb ? the latter being the type library that in earlier versions was included within the .ocx file. However that is really irrelevant since you never have to actually touch these files. ? The ActiveX control is registered by the API installer, so no need to do anything extra in that regard. The only thing that’s different is that when you add a reference to the ActiveX control to your project, the thing to look for is CSharpAPI rather than TWSLib or whatever it used to be. ? After that everything works exactly the same as before. ? By the way, don’t attempt to use the CSharpAPI.dll in E:\TWS_API\source\CSharpClient\client\bin\Release in this way, because that’s a pure .Net assembly that has no COM visibility. ? Richard ? ? ? From: [email protected] [mailto:[email protected]] On Behalf Of rwk
Sent: 03 October 2017 19:22 To: [email protected] Subject: Re: [TWS API] ActiveX in API version 9.72 and later ? On Tue, Oct 3, 2017 at 11:06 am, Nick wrote:
That's Ross Hemingway's product, and it's still available.? I used it in the past, but I switched to the ActiveX because the latter is or WAS supported by IB.? A product supported by the broker seemed more secure. |
|
On Wed, Oct 4, 2017 at 06:55 am, Richard L King wrote:
I readily admit I am not a Delphi expert, being entirely self-taught with a little help here from BeeJay.? After many hours of scouring the Internet I was only able to find one page about how to access an ActiveX created by someone else.? That page became my "cheat sheet". Prior to API 9.72, I imported the ActiveX (via the .OCX) and installed it on the component palette.? Then I dropped the component on a form and was able to reference it.? With API 9.72 and later, the import fails, and I have no idea how to add a reference to the ActiveX control in my project without a component. It appears that there is nobody else here trying to do this, so I guess I should stop wasting bandwidth on this forum.? I appreciate the assistance I have gotten to this point.? I am still able to run my system, and hopefully that will continue. Thanks, [rwk] |
|
On Wed, Oct 4, 2017 at 11:45 am, Josh wrote:
The ActiveX installer is only compatible with 32 bit applications in 9.72+ at the moment, whereas in 9.71 it could be used with either. Could that be the issue?That's an additional complication I have been considering.? I have been trying to access the 9.73 ActiveX with both Delphi2009 and Delphi 10.2 (the latest).? Delphi2009 only produces 32-bit programs, and I think version 10.2 will do either. With API 9.71 and earlier, the .OCX appears in the list of registered ActiveX's in the Delphi IDE.? With API 9.72, it's the .TLB that shows up as an ActiveX.? Importing the .TLB as either an ActiveX or typelib produces an error. |
开云体育I’m not a Delphi user, but other IDEs (including VB6 and the VBA IDE’s in Excel, Word etc) allow you to browse for a reference. I mean that alongside the list of registered ActiveX’s is a ‘Browse’ button: clicking on that enables you to navigate to the TWSLib.dll. I’d be surprised if there wasn’t something similar in Delphi. ? Also,, you don’t actually need to have the ActiveX appear in the component palette. Once you’ve got a reference to the dll in your program, you can declare your API object and create it like any other object. For example, my VB6 program that I mentioned earlier does exactly that. ? First it declares a form member variable that can fire events: ? Private WithEvents Tws1 As Tws ? Then, in the form’s Load event handler it instantiates it: ? Set Tws1 = New Tws ? Then it can call API methods in the normal way: ? Tws1.Connect "", 7496, 123, False Tws1.reqMktData mNextTickerId, symbol, sectype, expiry, 0#, "", "", exchange, primaryExchange, currencyCode, "", False, Nothing ? And so on. ? There must be an equivalent way to do this in Delphi. ? Richard ? ? From: [email protected] [mailto:[email protected]] On Behalf Of rwk
Sent: 04 October 2017 19:55 To: [email protected] Subject: Re: [TWS API] ActiveX in API version 9.72 and later ? On Wed, Oct 4, 2017 at 11:45 am, Josh wrote:
That's an additional complication I have been considering.? I have been trying to access the 9.73 ActiveX with both Delphi2009 and Delphi 10.2 (the latest).? Delphi2009 only produces 32-bit programs, and I think version 10.2 will do either. |
|
You're assuming that C# is difficult. It's not. You don't need the complicated bits, just the basic stuff. Get the "C# pocket reference" from amazon and speed read it. It's VERY concise. If you get stuck on anything then skip it and keep going. Go back later and read it again, if it still doesn't make sense then you probably don't need it. You will have a basic working knowledge of c# by Monday. Get Visual Studio 2017 community edition. It's free. It's very good. Sent with Secure Email.
|
|
On Thu, Oct 5, 2017 at 03:34 am, Jason wrote:
I'm a step ahead of you here.? I have VS2017 installed, and I had written a test app in C# to access the ActiveX in Telechart 2007.? The problem I ran into was that when I think about converting my Pascal codebase, I get overwhelmed.? I took my first college programming course in 1965 and thought it was really cool.? I'm still a geek, but programming is decidedly less cool now, and my mental sharpness has lost it's edge. Richard's latest comment has prompted a new line of thought on how to access the TWSAPI ActiveX in Delphi.? My inclination is to build on what I know, as I find it hard to think about how to program while thinking about how to take money out of the markets.? I may have a look at C# (or Java or Python) again, but I plan to stick with Delphi as long as I can. |
|
My first instinct is to take the more "courageous" approach of remaking it as quickly as possible in c#. It's probably a lot easier than being shackled to delphi. It's 20+ years since I wrote any pascal but I remember it being essentially the same as c# with similar syntax. Perhaps you use a lot of delphi libraries that would be difficult to reimplement. There are probably good equivalents in C#. If it's too much work to convert the existing code base to c#, and the delphi interface to IB is not working, then perhaps you can make an interface by passing text files instead. If you're just sending commands/status then this can work without the slowness being a problem. I do this with Sierrachart and IB. I have some C++ running on Sierrachart that writes files to a known folder. My stand-alone IB client reads the files and processes the orders based on the current IB client state. The IB client deletes the files when it reads them and writes the IB status to a known file so the Sierrachart side can display my orders and positions on the charts. (all because I found the Sierra IB order implementation to be unreliable and it wasn't possible to call IB directly from their C++ processspace) I appreciate that this may not fit with the programming model that your delphi/pascal code runs, the round-trip time for each "message" is quite long for example. -Jason Sent with Secure Email.
|
|
On Fri, Oct 6, 2017 at 12:06 am, Jason wrote:
Thanks for the feedback.? I agree that C# would be a sensible substitute for Delphi, as there appears to be a nearly one-to-one correspondence in commands.? I bodged together a test program in C# to access the TeleChart database which uses an ActiveX, and that went well enough, but the structure of the program was "different". Whenever "language wars" break out, I always say the best language to use is the one you already know ... unless it's Fortran or Cobol, then you should change.? :-)? I find the proliferation of modern programming languages bewildering. I am surprised that Richard was able to get VB6 to play nicely with API 9.72, but I don't know VB6 any better than C# (or C/C++).? Yesterday I took another unsuccessful deep dive into interfacing Delphi with API 9.72.? I don't think I will spend any more time on it.? I'll probably press on with C#. |
|
there's an absurd turnover of new "must-try" languages, frameworks etc etc. Most of them are forgotten after a year or 2. Makes it hard to determine what is worth the effort. Is the app graphical? do you have a user interface with charts or buttons or is this just a text, tabular, command and status type thing? If you can find an example showing delphi interface through COM then it would give hope that the approach is worth persisting with. It might be documented somewhere. Sent with Secure Email.
|
|
On Sat, Oct 7, 2017 at 06:55 am, Jason wrote:
I agree about the "new stuff".? Some of it is good, but most has a short lifespan that is rightly soon forgotten. My app is graphical, mostly automated, and cannot tolerate a delay between detecting a trade and placing an order.? According to the docs, the ActiveX can lose events under certain conditions.? I have never noticed such a problem. All the examples I have found, except the one that became my cheat sheet, are about how to write an ActiveX or use one I just wrote.? I think Richard is probably right that it should be possible to access the 9.72 ActiveX directly without installing it as a component.? I am pretty confident that there is no easy, straightforward way to do that.? I think I need a tool to see inside the ActiveX to find the names of objects that are exported to the outside world, and I'm not sure I want to go to that extreme.? I might try StackExchange or some such venue for advice. [rwk] |
|
>and cannot tolerate a delay between detecting a trade and placing an order. It depends what kind of delay you are talking about. I 'watch' the directory that I write my trade files into using the win32 OS fundtion call "FindFirstChangeNotification" and then "WaitForMultipleObjects". So as soon as the file is written, my IB Client notices the directory change, reads the file and processes the trade. It's a fraction of a second. I've never measured it, but it seems near-enough instant from a human perspective. I can share a code snippet if you like. My IB client is written in C++ but I think there is a newer version that's easier to use for c# called FileSystemWatcher. Or something. The C++ (win32) version has a few gotchas, so you would be advised to just copy my code rather than trying to invent the solution yourself. Here's the C# version The files I drop into the folder are empty, zero bytes. The filename contains the actual trade instruction. -Jason Sent with Secure Email.
|
|
On Sat, Oct 7, 2017 at 10:15 am, Jason wrote:
It sounds like I am doing something similar.? My app has controls to tweak the trading (mostly risk levels), but the actual order creation and submission is automated.? I could let my app run unattended, but a lot can go wrong, and there isn't much benefit to taking it that far.? I re-sync my clock each day, as I need it to be correct within a second. |
to navigate to use esc to dismiss