MULTICHARTS .NET 9.0 RELEASE

This version is a big step forward for our platform. We added a huge feature – real-time portfolio trading through all available brokers! In this version we also concentrated on dramatically improving individual and portfolio backtesting, making it the most accurate version ever. We added new functionality of a second pass when calculating the portfolio, which opens possibilities like rotational trading, pair trading and other interesting implementations. Portfolio Trader now also has walk-forward optimization and custom fitness function. Learn more here

Download MultiCharts .NET 9.0 RELEASE

Portfolio Trader Manual: Wiki, PDF.

Good release, thank you!

Is there also a list of code breaking changes? I could not find it in the release blog posts, but perhaps I overlooked it.

I'm asking because with the new release I get the message that:

'PowerLanguage.TradeManager.Order' does not contain a definition for 'Symbol' and no extension method 'Symbol' accepting a first argument of type 'PowerLanguage.TradeManager.Order' could be found (are you missing a using directive or an assembly reference?)

'PowerLanguage.TradeManager.Order' does not contain a definition for 'BrokerID' and no extension method 'BrokerID' accepting a first argument of type 'PowerLanguage.TradeManager.Order' could be found (are you missing a using directive or an assembly reference?)

'PowerLanguage.TradeManager.Position' does not contain a definition for 'Symbol' and no extension method 'Symbol' accepting a first argument of type 'PowerLanguage.TradeManager.Position' could be found (are you missing a using directive or an assembly reference?)

These messages occur in my own code, but also in "Test_TradeManager_4" which I downloaded of the forum from MC support.

Good release, thank you!

Is there also a list of code breaking changes? I could not find it in the release blog posts, but perhaps I overlooked it.

Hello JoshM,

Thank you for your feedback.
Symbol was renamed into BrokerSymbol.
BrokerID was replaced with BrokerSpecificID.

Is there the chance that Volume Profile information will be present during an optimization with one of the next releases? Meaning is this planned to be implemented, not going to happen or not even considered as of now?

Thank you,
ABC

Is there the chance that Volume Profile information will be present during an optimization with one of the next releases? Meaning is this planned to be implemented, not going to happen or not even considered as of now?

Thank you,
ABC

Hello ABC,

This is not something that is in our to-do list at the moment.

Henry,

can you elaborate on why this wasn't implemented, specifically on the rational behind this?

From a user point of view this seems like a serious shortcoming when you implement volume profile information into a platform geared towards automated trading, but then cutting it's use short by removing the information again when one wants to properly develop and test a signal within MC that works with this information.

Thank you,
ABC

Is there the chance that Volume Profile information will be present during an optimization with one of the next releases? Meaning is this planned to be implemented, not going to happen or not even considered as of now?

Thank you,
ABC

Hello ABC,

This is not something that is in our to-do list at the moment.

Henry,

can you elaborate on why this wasn't implemented, specifically on the rational behind this?

From a user point of view this seems like a serious shortcoming when you implement volume profile information into a platform geared towards automated trading, but then cutting it's use short by removing the information again when one wants to properly develop and test a signal within MC that works with this information.

Thank you,
ABC

ABC, the implementation of this feature was not planned to any version yet. Even though we value your opinion not all requests can be implemented due to the fact that some features do not fit into our current roadmap. If you have any suggestions that you want to have implemented - you can send them directly to support@multicharts.com and they will be forwarded to the management.

MultiCharts .NET 9.0 Release 2 builds 10176/10177 is out now!
You can check the change log in our blog.

MultiCharts .NET 9.0 Release 3 builds 10254/10255 with OANDA support is out now!
>>>Go to download page<<<

OANDA datafeed connection instructions

OANDA broker connection instructions

Henry, would it be an idea to create an enumeration to signal the direction of an arrow? Currently, it works like:
I use MC (.NET) for a while now, but still don't find this `true` or `false` argument intuitive: occasionally I still have to refer to the MultiCharts PowerLanguage wiki or try to see whether I need to use `true` or `false`. Worse yet, IntelliSense does not say what `true` and `false` mean. It simply says: "bool direction: Arrow direction".

So perhaps an overloaded `DrwArrow.Create()` method can be created that works something like this?

Henry, would it be an idea to create an enumeration to signal the direction of an arrow? Currently, it works like:

Code: Select all

arrowDown = DrwArrow.Create(ArrowDownLocation(), true);

I use MC (.NET) for a while now, but still don't find this `true` or `false` argument intuitive: occasionally I still have to refer to the MultiCharts PowerLanguage wiki or try to see whether I need to use `true` or `false`. Worse yet, IntelliSense does not say what `true` and `false` mean. It simply says: "bool direction: Arrow direction".

So perhaps an overloaded `DrwArrow.Create()` method can be created that works something like this?

Code: Select all

arrowUp = DrwArrow.Create(ArrowUpLocation(), EArrowDirection.Up);

Code: Select all

arrowDown = DrwArrow.Create(ArrowDownLocation(), EArrowDirection.Down);

Hello JoshM,

Thank you for your suggestion. It has been forwarded to the developers.

MultiCharts .NET 9.0 Release 4 builds 10361/10362 is out now!

Check What's new in these builds

>>>Go to download page<<<

Some memory leaking in .NET?

I exported my entire database from MC PL using QM's export tool.
I then imported that database into QM's .NET.

Here's the result:



I remember receiving an error of some missing data while importing but that did not stop the import to continue. Could that generated this wild memory consumption?
The export file size has 5.2gb.

I sent the logs to you guys. Maybe there's something there.

It would be very welcomed if indeed MC PL and .NET could share the same database.
Maybe not in the case of both programs could access the same files since if both are open at the same time, accessing and receiving real time data into the same file could generate some errors but make the entire database folder with all the files in it be compatible between PL and .NET versions. This way a simple copy/paste would allow us to have both platforms with an identical database in seconds instead of having to import/export.

Today I made the test and copy/paste PL database folder into .NET but I ended up not having any data provider available.
I then only copy/paste the tsstorage.gdb and the excel files. This time I had the data providers available but none of the symbols I add recently in PL version.
I ended up not knowing if tsstorage.gdb is indeed compatible with .NET since none of the recently added symbols were available.

Hello arnie,

Is the memory/CPU usage constant for the entire import period or it was just a spike?
Basically this can happen when processing lengthy tick data.

Hello arnie,

Is the memory/CPU usage constant for the entire import period or it was just a spike?
Basically this can happen when processing lengthy tick data.

It's constant for the entire import period.

I ended up making several export files because the entire database (5gb) ended up making my computer hang. It use all the 12gb of memory.

By creating several files, the biggest one had 1gb of size and used 6gb of memory to import it. After the import was complete memory usage came back to normal.

So if to import a database, in my case it need more then 12gb maybe you should update the tech specs of MC for power users. Instead of 8gb you should put 20gb or more because 8gb really falls short when you need to import a lengthy database.

Again, if the PL database (Database folder) was shared/100% compatible with .NET this process would be a lot easier.

arnie, please send me this 1 gb file and our developers will check if there is anything we can improve when importing this file.

On MultiCharts .NET64 Version 9.0 Release (Build 10016), it takes around 20-25 seconds before the PowerLanguage .NET Editor starts after clicking on the icon. Is there anything I can do to speed up this process? Other applications on my pc start with normal speed.

(Windows 7 SP1, 8GB DDR3 666mhz, SSD drive, 3.6Ghz quad-core CPU, and Windows Performance Index of 6.7)

On MultiCharts .NET64 Version 9.0 Release (Build 10016), it takes around 20-25 seconds before the PowerLanguage .NET Editor starts after clicking on the icon. Is there anything I can do to speed up this process? Other applications on my pc start with normal speed.

(Windows 7 SP1, 8GB DDR3 666mhz, SSD drive, 3.6Ghz quad-core CPU, and Windows Performance Index of 6.7)

Hello JoshM,

It takes 5-6 seconds to start the PowerLanguage .NET Editor using this build of MultiCharts .NET on my PC. I will consult with our developers regarding your case and get back to you.

Thanks Henry. I don't think it's necessary to explore further; when I add the PLEditor.NET.exe file as an excluded process of the virus scanner (Microsoft Security Essentials) it starts in 6 seconds. I'll check it again tomorrow to see if it also starts quickly when I haven't run it yet during my Windows session.

Hiya JoshM,

Not the same build number as you report, but just thought more feedback for you may be appropriate. MC.net 9.0 build 10362 starts the PLEditor in 2-3 seconds. I have no virus software on my trading computer.

All my best,
MK

Not the same build number as you report, but just thought more feedback for you may be appropriate. MC.net 9.0 build 10362 starts the PLEditor in 2-3 seconds. I have no virus software on my trading computer.

Thanks, good to know because then it seems to be related to my pc/software.

I'll look at other software on my pc, but with excluding it from the virus scanner it already starts considerably faster (also for the first start of the Window session).

MultiCharts .NET 9.0 Release 5 builds 10716/10717 is out now!

Check What's new in these builds

>>>Go to download page<<<

As a small feature request, can the `IDrawObject.Locked` property also get a `get` access property? Currently it can only be set:

IDrawObject.Locked Property
Lock drawing on the chart. Lock for drawings prevents it from unnecessary user changes.

public bool Locked { public set; }

If we can also retrieve the `Locked` value, we can write code that toggles a trend line's locked state from on to off, for example.

All other `ITrendLineObject` properties (like `Color` and `Size`) are already get/set.

As a small feature request, can the `IDrawObject.Locked` property also get a `get` access property? Currently it can only be set:

IDrawObject.Locked Property
Lock drawing on the chart. Lock for drawings prevents it from unnecessary user changes.

public bool Locked { public set; }

If we can also retrieve the `Locked` value, we can write code that toggles a trend line's locked state from on to off, for example.

All other `ITrendLineObject` properties (like `Color` and `Size`) are already get/set.

Thank you for your suggestion. This improvement is scheduled for MultiCharts .NET 9.1 Beta1.

New builds (10760/10761) of MultiCharts .NET 9.0 Release with the fix for the "Cannot access Currency Conversion Server" issue have been published on our website. Please update your MultiCharts to get the fix.

MultiCharts .NET 9.0 Release 7 builds 11211/11212 is out now!

Check What's new in these builds

>>>Go to download page<<<