Calling TWS ActiveX from C#

Quote from nononsense:



Trader.NET

You are a bum.

nononsense
More...

Which one?:D:D:D

bum1 ( P ) Pronunciation Key (bm)
n.
A tramp; a vagrant.
A lazy or shiftless person, especially one who seeks to live solely by the support of others.
An incompetent, insignificant, or obnoxious person: The batter called the pitcher a bum.
One who is devoted to a particular activity or milieu: a beach bum.

v. bummed, bum·ming, bums
v. intr.
To live by begging and scavenging from place to place. Often used with around.
To loaf.

v. tr.
To acquire by begging; cadge. See Synonyms at cadge.
Slang. To depress, dishearten, or dismay. Often used with out.

adj.
Inferior; worthless: gave me bum advice; did a bum job of fixing the car.
Disabled; malfunctioning: a bum shoulder.
Unfavorable or unfair: got a bum deal on my final grade for the course.
Unpleasant; lousy: had a bum time at the party.

Idiom:
on the bum
Living as a vagrant or tramp.
Out of order; broken.
 
I bought some very sophisticated Numerics libraries.

nitro
Quote from laziz314159:



Ok, now I'm just interested in what you purchased..

--laz
More...
 
Trader,

Yeah, I am just dreaming at this point.

It is great that you have done all the work to do the ports. I wish I had the time...

nitro

Quote from Trader.NET:



nitro,

You don't really have many options:

1. You wrap all you C++ stuff into .NET classes (a lot of work indeed) and dive into C# world.
2. You use interop (a lot of Pinvoke and marshalling codes, it's tough that you have to write so much code to make a single call if the non-primitive types are in the arguments:-().
3. You use C# only for new stuffs and wrap the C++ in some high level API (so you don't have to deal with all tedious mapping for every function call, depending on how well the c++ classes/templates are designed for refactoring posibility) with managed C++.
4. You forget about C# crap and stick with your C++:-)

BTW, wrapping c++ as ActiveX (it is really COM) is much harder than wrapping it to .NET classes.

The reason the compiler can not help is that the compiler does not understand the c++ interface enough to know how to marshall those wierd pointers back and forth between .NET and C++ call. It's the same reason why COM can be wrapped successfully most of time by a tool, but it does not work 100% time since even in COM world, people still do weird stuffs.

We have done a lot of work retooling C++ numercial analysis and process control libs for use in .NET world, it's not easy.
More...
 
Quote from nitro:

I bought some very sophisticated Numerics libraries.

nitro
More...

I have some third party stl based libraries which I use - although a majority of the run-of-the mill stuff is simply executed within Mathematica since it has very reliable and highly tested algorithms.

The approach I have used to integrate these is the approach I have employed for about the last 4 years: Let the subsystems stand alone and build xml wrappers for the interactions. Each system simply accepts and spits out xml. At first this seems like a lot of work - and it is. However, I can leverage my prior work - tools, utilities etc - and this allows me to locate the subsystems anywhere or swap out backend processing systems without having to retool the interfaces.

Even though this is a lot of work it has payed off in a big way.
If you are going to have to integrate all of this you might consider this route for the future .......
 
Hi,

What are you fellows trying to accomplish? If you are out to make some money with this all you need to be quite a bit more practical. Ok if you fell in love with C#, nothing against it. But is it worth all the trouble if you can get the TWS API to work without effort with sockets in C++ or Activex in VB6?

I shelved the whole thing and am glad I did reading the many posts on ET and elsewhere of the brave. I learned a long time in software development to steer away from messy stuff. Come back to it after a year or so, it might very well go like a breeze. In the meantime you better put your time in more fruitful endeavors.
You will find no honor in laboriously "solving" immature software riddles but vain self deceit.

Remember Bjarne Stroustrup's warning: "Expensive toys unfit to solve real problems".

nononsense
 
CalTrader,

I assume you are using MathLink?

nitro
Quote from CalTrader:



I have some third party stl based libraries which I use - although a majority of the run-of-the mill stuff is simply executed within Mathematica since it has very reliable and highly tested algorithms.

The approach I have used to integrate these is the approach I have employed for about the last 4 years: Let the subsystems stand alone and build xml wrappers for the interactions. Each system simply accepts and spits out xml. At first this seems like a lot of work - and it is. However, I can leverage my prior work - tools, utilities etc - and this allows me to locate the subsystems anywhere or swap out backend processing systems without having to retool the interfaces.

Even though this is a lot of work it has payed off in a big way.
If you are going to have to integrate all of this you might consider this route for the future .......
More...
 
I just downloaded .Net/Link. Do I need mathlink also?

Do you run this stuff in realtime, or at during off-tradng hours to get "tomorrow's" numbers?

nitro
Quote from CalTrader:



Mathlink and .Net/Link
More...
 
There is one more way - implement different exe's that encapsulate .net and c++ stuff, and communicate thru (named ?) pipes.

This is the route I am thinking of taking. In effect, the exes act as a wrapper around the different platforms, and instead of sending data structures across a thread boundary, you send data across the pipe across process boundaries. This is the way Unix does things (treats everything as a file and pipes ouputs into inputs,) and I really see the benefit now of this design pattern...

nitro
Quote from Trader.NET:



nitro,

You don't really have many options:

1. You wrap all you C++ stuff into .NET classes (a lot of work indeed) and dive into C# world.
2. You use interop (a lot of Pinvoke and marshalling codes, it's tough that you have to write so much code to make a single call if the non-primitive types are in the arguments:-().
3. You use C# only for new stuffs and wrap the C++ in some high level API (so you don't have to deal with all tedious mapping for every function call, depending on how well the c++ classes/templates are designed for refactoring posibility) with managed C++.
4. You forget about C# crap and stick with your C++:-)

BTW, wrapping c++ as ActiveX (it is really COM) is much harder than wrapping it to .NET classes.

The reason the compiler can not help is that the compiler does not understand the c++ interface enough to know how to marshall those wierd pointers back and forth between .NET and C++ call. It's the same reason why COM can be wrapped successfully most of time by a tool, but it does not work 100% time since even in COM world, people still do weird stuffs.

We have done a lot of work retooling C++ numercial analysis and process control libs for use in .NET world, it's not easy.
More...
 
Quote from nitro:

I just downloaded .Net/Link. Do I need mathlink also?

Do you run this stuff in realtime, or at during off-tradng hours to get "tomorrow's" numbers?

nitro
More...

.. Depends upon what you are communicating with ... If it is native .Net Framework stuff then no .... If you have other older Com/Com+ components that you need to communicate with then you might need Mathlink ...

I run Mathematica's Kernel in Real-time during trading hours and in off-hours processing tasks.
 
You must log in or register to reply here.
Back
Top