Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
since a while I'm trying to build a setup where I can outsource algorithms from MC to C#. I'm not familiar with C++ but did lots of things in C# (except COM-related things), hence my choice for C#. There is a PDF (EasyLanguage_Extension_SDK) and a few threads regarding the interface IEasyLanguageObject (Defined on side of EasyLanguage/Powerlanguage) on the MC-Forum.
What I'm aiming to do is a MC-Indicator calling a C#-Method. The indicator is using {self} to pass a reference to itself and its context (like [n]bars Close, Open, ...). I've created the necessary C++-Interop-DLL in order to communicate with managed code (C#). The reference overgiven from the indicator can be used within my C++-Code. The appropriate interface is IEasyLanguageObject . I can access all necessary data via this interface. Now the problem is forwarding that reference further from my C++-Interop-DLL to C#. Exchanging primitive types via MC <--> C++ <--> C# is no problem at all, works as it should. Both DLLs use PLKit.dll for the type-definitions like IEasyLanguageObject for example.
My approuch: passing the ref from C++ to C# the best way is likely using IntPtr on both sides. Retrieving the interface for the reference from that pointer is the main problem. There are many things regarding the interaction between COM and managed code.
I wonder if anyone here has figured out how to retrieve and access the IEasyLanguageObject -Interface from C#.
Is anyone here is using IEasyLanguageObject from C# passed as a reference? I'm not using MC.Net, just the normal MC-Version. Any help appreciated.
Can you help answer these questions from other members on NexusFi?
I don't know how much time you have already spend with this project, but you'll probably spend some more with it. That's why I thought it might make sense to go with the .NET version, even more so as you are versatile with C#.
You can probably get a discount for MC.NET as you have already a license for the regular version. Just my two cents, in the end I don't know how much code you have to convert etc. and you have probably done the math about switching already.
Actually off-topic ... In fact, you are right and I did a proof of concept with calling my dll from MC.Net. Easy going! They charge 199$ for converting the license, which is imho ok. But there are things that kept me from really migrating to the .Net-Side.
Indicator on Indicator was proposed for version 9 (MC-Statement from spring 2013) but not anymore after I asked them about it
programming this for my own in my indicators and doing this for builtin-indicators via a wrapper would be ok for me but I can't see a way to do this. The suggested examples for this given on MC-Forum are not related to what I need to do. I have an example on the support forum ... maybe this can be done easily and I've just overseen something.
One big minus is the two missing default settings - checkbox in the Format-Study-Dialog for Input and Style. Applying a default is not possible ... implementing the checkboxes for MC.Net is not possible according to the support. This might sound like a minor problem but can get a real nightmare.
Another point I came upon is the PLE being in charge of the .Net-Projects for C# and VB. This of course was meant to be that way in order to realize the integration of extern editors, so far no problem. But one has to be aware that from time to time PLE is doing something in the background causing the project to change. Actually no problem either. But in case there is getting something wrong the user can do nothing. One example: for me I've converted half a dozens of bigger indicators on the C#-Side, never did anything on the VB-Side. But from nothing after starting VS from PLE the VB-Project was missing the reference to PLStudiesProxy.dll, hence almost 200errors ... of course they don't count because compilation is done by the PLE but Intellisense and normal development hardly possible. As PLE triggering the generation/change of the two projects I couldn't change this wrong project. Strange but true on PLE-Side the project was fine. The support asked me to send the code in order to investigate but thats hardly possible here. So in the end there's a lot happening under the hood when dealing with .Net-Version which the developer is not in charge of.
It's told the functionality of MC and MC.Net is the same but thats obviously not true for some specific things. I've checked the .Net-Forum and it looks like there are some other points ... maybe no big deal either but surprise when one is recognizing this.
--> so for me it would take long time to migrate due to the huge amount of code and some things got me thinking hardly whether it's really worth migrating. I've put much time into evaluating but at the moment for me it's better to stick with my MC-Configuration.
AddOn: Regarding my second point this could be possible with Lambda-Expressions I've read on MC-Forum. There's a class defined for Multicharts: Powerlanguage.Lambda<T> : ISeries<T>
m_rsi.price = new Lambda<double>(_barsBack0 => (Bars.Close[_barsBack0] * 2));