Calling TWS ActiveX from C#
- Thread starter nitro
- Start date
Using ActiveX with .NET is like docktapping your Lexus
Look at the java sample code, any decent programmer can port it into C# in no time.
Nononsese,
You can't program, so you bitch about how hard to code
Look at the java sample code, any decent programmer can port it into C# in no time.Nononsese,
You can't program, so you bitch about how hard to code
Quote from nitro:
nononsense,
Thanks for the warnings. I have used C# to write some very powerful apps. My experience differs from yours somewhat.
One thing I really hate about C# is that there is no clean way to call old style C++ libraries/dll's - you have to go thru this Interop crap. I should just be able to say:
extern unmanaged C { //nitro invented this syntax
#include oldstyle.h
}
And the compiler should take care of the rest.
nitro
Managed VC++ does it.
Bro,
ActiveX, IMHO, is not the way to go for things like Michaels is doing. The reason I am using ActiveX is that it is the cleanest way as of today (AFAIK) to use IB's API with C#, which I am using to do stuff that is not time critical.
When I move to the RealTick datafeed, they have a native .Net library which I can use with C#, or I will use straight sockets.
Thanks for the heads up.
nitro
ActiveX, IMHO, is not the way to go for things like Michaels is doing. The reason I am using ActiveX is that it is the cleanest way as of today (AFAIK) to use IB's API with C#, which I am using to do stuff that is not time critical.
When I move to the RealTick datafeed, they have a native .Net library which I can use with C#, or I will use straight sockets.
Thanks for the heads up.
nitro
I mean you would use VC++ if you have to use a lot of non-managed c++ stuffs. Or you have to do interop or wrap it with managed c++. Do a goggle on Quake2 .NET for how to integrate c/c++ stuff with .NET.
Quote from Trader.NET:
Using ActiveX with .NET is like docktapping your Lexus
Nononsese,
You can't program, so you bitch about how hard to code
Trader.NET
You are a bum.
nononsense
Trader.Net,
OK, I found that - interesting - thx for the heads up.
But what I want to do is: I have dll's that I bought that do all kinds of nifty stuff. They are written in C++ and they come with source.
I just want to call them from C#, so I _believe_ I have to do an enourmous amount of work to call those unmanaged C++ functions from C# (and I still do not see how managed C++ makes this easier than in C#,) since there are include files that have complex classes, templates, etc, and functions that take these classes/templates as parameters. This is not like calling a function that takes an int.
I guess a good analogy as to the complexity that I am facing and an interesting example would be: Show how to call an old C++ STL function in a .dll that takes a complex set of parameters from C#. And also interesting would be, show why and how this would be easier from managed C++ (if it is) ?
Like I said, AFAIK, this is not trivial. If you think about it, there is no reason why I should not be able to say:
extern "unmanaged C" { //nitro invented this syntax
#include unmangedcode.h
}
and have the compiler do all the work
What is really funny to me is that, if the .dll was offered as an ActiveX dll, all would be fine and dandy, as it is super easy to use ActiveX dll's from C# - LOL! -ugh -
So there is another question - how hard is it, comparitively to doing the managed Interop stuff on non-trivial functions, to turn an old style .dll into an ActiveX .dll if you have access to source code? I wish there was just a tool that did this...
The "It just works" only "works" (easily) for trivial functions - AFAIK.
nitro
OK, I found that - interesting - thx for the heads up.
But what I want to do is: I have dll's that I bought that do all kinds of nifty stuff. They are written in C++ and they come with source.
I just want to call them from C#, so I _believe_ I have to do an enourmous amount of work to call those unmanaged C++ functions from C# (and I still do not see how managed C++ makes this easier than in C#,) since there are include files that have complex classes, templates, etc, and functions that take these classes/templates as parameters. This is not like calling a function that takes an int.
I guess a good analogy as to the complexity that I am facing and an interesting example would be: Show how to call an old C++ STL function in a .dll that takes a complex set of parameters from C#. And also interesting would be, show why and how this would be easier from managed C++ (if it is) ?
Like I said, AFAIK, this is not trivial. If you think about it, there is no reason why I should not be able to say:
extern "unmanaged C" { //nitro invented this syntax
#include unmangedcode.h
}
and have the compiler do all the work
What is really funny to me is that, if the .dll was offered as an ActiveX dll, all would be fine and dandy, as it is super easy to use ActiveX dll's from C# - LOL! -ugh -
So there is another question - how hard is it, comparitively to doing the managed Interop stuff on non-trivial functions, to turn an old style .dll into an ActiveX .dll if you have access to source code? I wish there was just a tool that did this...The "It just works" only "works" (easily) for trivial functions - AFAIK.
nitro
Quote from nitro:
Trader.Net,
OK, I found that - interesting - thx for the heads up.
But what I want to do is: I have dll's that I bought that do all kinds of nifty stuff. They are written in C++ and they come with source.
nitro
Ok, now I'm just interested in what you purchased..
--laz
Quote from nitro:
Trader.Net,
OK, I found that - interesting - thx for the heads up.
But what I want to do is: I have dll's that I bought that do all kinds of nifty stuff. They are written in C++ and they come with source.
I just want to call them from C#, so I _believe_ I have to do an enourmous amount of work to call those unmanaged C++ functions from C# (and I still do not see how managed C++ makes this easier than in C#,) since there are include files that have complex classes, templates, etc, and functions that take these classes/templates as parameters. This is not like calling a function that takes an int.
I guess a good analogy as to the complexity that I am facing and an interesting example would be: Show how to call an old C++ STL function in a .dll that takes a complex set of parameters from C#. And also interesting would be, show why and how this would be easier from managed C++ (if it is) ?
Like I said, AFAIK, this is not trivial. If you think about it, there is no reason why I should not be able to say:
extern "unmanaged C" { //nitro invented this syntax
#include unmangedcode.h
}
and have the compiler do all the work
What is really funny to me is that, if the .dll was offered as an ActiveX dll, all would be fine and dandy, as it is super easy to use ActiveX dll's from C# - LOL! -ugh -
The "It just works" only "works" (easily) for trivial functions - AFAIK.
nitro
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.