I am on TS 9 and would switch to MC.NET in a heartbeat if I were able to run the many sophisticated indicators I've already written in EasyLanguage without having to record them into VB/C#.
I would then be able to focus on some improved strategy ideas I have that can only really be written and maintained in something like C#.
If MC can add the ability to at least execute EasyLanguage functions from MC.NET then they'd have at least my sale and from this thread it seems quite a few others.
At least allow execution of EL code in MC.NET
- JoshM
- Posts: 2195
- Joined: 20 May 2011
- Location: The Netherlands
- Has thanked: 1544 times
- Been thanked: 1565 times
- Contact:
Re: At least allow execution of EL code in MC.NET
Wouldn't it be more helpful to you (and others) if PowerLanguage is expanded to be fully compatible with TS' EasyLanguage? Then you don't need a "bridge" to MC .NET in the first place.I am on TS 9 and would switch to MC.NET in a heartbeat if I were able to run the many sophisticated indicators I've already written in EasyLanguage without having to record them into VB/C#.
I would then be able to focus on some improved strategy ideas I have that can only really be written and maintained in something like C#.
If MC can add the ability to at least execute EasyLanguage functions from MC.NET then they'd have at least my sale and from this thread it seems quite a few others.
There are, by the way, no EasyLanguage functions in MC .NET that work like TS. If you want something like a custom window or chart drawing, you need to code that yourself in MC .NET -- the standard functions in MC .NET that you're asking for to be able to execute in PowerLanguage are the same.
Re: At least allow execution of EL code in MC.NET
Hi, I think I was a bit unclear.
The sophistication of the strategies I want to write lend themselves to being written in C# - especially since I am familiar with the language and .NET. The existing functions I have are written in EasyLanguage but should be relatively portable to PowerLanguage.
What I'd like, is to leverage the existing EL (I am almost certain PL compatible) code from C#.NET
The sophistication of the strategies I want to write lend themselves to being written in C# - especially since I am familiar with the language and .NET. The existing functions I have are written in EasyLanguage but should be relatively portable to PowerLanguage.
What I'd like, is to leverage the existing EL (I am almost certain PL compatible) code from C#.NET
-
- Posts: 401
- Joined: 19 Jan 2011
- Location: Netherlands
- Has thanked: 85 times
- Been thanked: 125 times
Re: At least allow execution of EL code in MC.NET
The use of PL code in MC.net would also be for me the trigger to buy a .net version of MC. But I also understand that MC may have other interests.
I think the .net version is the future anyway. But to learn a new language and code all my PL code with C#, is to much work and time consuming all at once, next to the day job called trading.
I would use the extra possibilities of .net in case it can't be done with PL. And learn the language and add functionality indicator by indicator as I go along. The gradual transition from PL to .Net is in this way much smoother I think and less of a hurtle.
I think the .net version is the future anyway. But to learn a new language and code all my PL code with C#, is to much work and time consuming all at once, next to the day job called trading.
I would use the extra possibilities of .net in case it can't be done with PL. And learn the language and add functionality indicator by indicator as I go along. The gradual transition from PL to .Net is in this way much smoother I think and less of a hurtle.
- Henry MultiСharts
- Posts: 9165
- Joined: 25 Aug 2011
- Has thanked: 1264 times
- Been thanked: 2957 times
Re: At least allow execution of EL code in MC.NET
Dear users,
Thank you for your feedback. At the moment we do not plan merging MultiCharts and MultiCharts .NET together/allowing execution of PowerLanguage code in MC.NET. We consider the current product line suitable for most of the users and provide discounts for additional licenses as well as ability to convert your license into a different product.
Thank you for your feedback. At the moment we do not plan merging MultiCharts and MultiCharts .NET together/allowing execution of PowerLanguage code in MC.NET. We consider the current product line suitable for most of the users and provide discounts for additional licenses as well as ability to convert your license into a different product.
Re: At least allow execution of EL code in MC.NET
Thank you for replying. I ask that you place my suggestion under consideration - it is simply infeasible to re-write all of the legacy EL/PL code into .NET, even for those who want to migrate over to MC.NET.
Some form of automated migration path / code conversion would be most welcome. Maybe even a CLR version of PL
Some form of automated migration path / code conversion would be most welcome. Maybe even a CLR version of PL
Re: At least allow execution of EL code in MC.NET
I faced a similar decision. I am currently biting the bullet and converting all my EL indicators and signals to C# (as and when time permits). I will always prefer to use EL for developing and the testing of new ideas or tweaks as it is much faster...... it is simply infeasible to re-write all of the legacy EL/PL code into .NET, even for those who want to migrate over to MC.NET.
An alternative to consider is what I did and create your own dll which completely bypasses MC and connects to the broker directly via their API when placing/modifying/canceling trades. For me, this was a much faster solution than rewriting and testing all my EL scripts in C#.
It has some other, very important advantages for me and my trade submissions are immediate (none of the one or more tick lag that Multicharts imposes). Exchange compliant orders are submitted 'as is' rather than undergoing Multicharts' mandatory conversions to Market Orders and the EL script is simplified in not needing to code a path to send exactly the same order(s) on every tick - even when there is no need for the order(s) to be changed. So, the overall processing time is much faster which was a welcome but unexpected benefit.
Downsides: You have to handle MarketPositions and a change of brokers would require a rewrite of the dll - but, once written, that becomes more of a conversion project than development.
Re: At least allow execution of EL code in MC.NET
Jad, I'm facing the EXACT choice here!
I spent the weekend moving over some stuff to MC.NET and it has been frustrating. No IEnumerable implementation (there is no 'good' reason for this as far as I can tell); basic functions like MEDIAN are not available out of the box, functions like XAverage only work on price bars and not on VariableSeries.
I've worked around a lot of these issues but then I found an open source gem: https://github.com/QuantConnect/Lean - so no charting which is a major blow but the API is clean and beautiful for an automated trader like myself.
Too many options.
I spent the weekend moving over some stuff to MC.NET and it has been frustrating. No IEnumerable implementation (there is no 'good' reason for this as far as I can tell); basic functions like MEDIAN are not available out of the box, functions like XAverage only work on price bars and not on VariableSeries.
I've worked around a lot of these issues but then I found an open source gem: https://github.com/QuantConnect/Lean - so no charting which is a major blow but the API is clean and beautiful for an automated trader like myself.
Too many options.
Re: At least allow execution of EL code in MC.NET
Yes - One of the problems when deciding to convert MC EL to MC.Net is not knowing how far in you'll get before you discover that MC.Net is not entirely ready for primetime as far as your EL scripts go. Some of the stuff I've written over the past 15+ years has been time-consuming and hairy enough developing it in EL. Conversion of it to PL/C# is going to take longer.
It was a gamble to go the dll route as there were many unknowns there too. It has taken about 6 weeks but that's much less than it's going to take to convert my EL code.
Good luck with whatever route you choose.
It was a gamble to go the dll route as there were many unknowns there too. It has taken about 6 weeks but that's much less than it's going to take to convert my EL code.
Good luck with whatever route you choose.