Nitro have you spoken with Michael about Active X? Even with all those Bangladeshi programmers at his disposal I think they had issues there, and substantial ones.
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
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
Trader.NET Does what? In general, from what I have seen, I think I would rather have a root canal than use managed C++. AFAIK, using Managed C++ to call non-manged C++ code in native DLL's is no easier in Managed C++ than in C#? 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.
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
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.