Discussion of article "Library for easy and quick development of MetaTrader programs (part I). Concept, data management and first results"
Useful article. Thank you.
It's gonna get more interesting from here. This is just the beginning.
Happy start, Artem! The code is on the level.
Good job, Artem! The code is on the level.
It's gonna get more interesting from here. This is just the beginning.
Artem, will there be a set of classes for creating trading experts in the future? The code will be universal and compiled for MT4 and MT5?
And what's the difference from the already established approach,create a trading robot in 6 steps?
And what's the difference from the already established approach,create a trading robot in 6 steps?
One question: why the outcry?
And a second question: what does that have to do with it?
One question: what's with all the shouting?
And the second question is, what's that got to do with it?
Sorry, I wanted to just copy and paste the title of the article, but I did. And the editor of the post does not show the content pasted in this way. So it wasn't in my post. ::2 I don't know I didn't get the point of the article, it's kind of like the idea of creating your own standard library.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
New article Library for easy and quick development of MetaTrader programs (part I). Concept, data management and first results has been published:
While analyzing a huge number of trading strategies, orders for development of applications for MetaTrader 5 and MetaTrader 4 terminals and various MetaTrader websites, I came to the conclusion that all this diversity is based mostly on the same elementary functions, actions and values appearing regularly in different programs. This resulted in DoEasy cross-platform library for easy and quick development of МetaТrader 5 and МetaТrader 4 applications.
Now all is compiled without errors, and data on all orders and deals in trading account's history are displayed in the terminal journal.
All properties of each order/deal, including unsupported ones, are displayed.
The fact is that we have developed the methods returning the flags for supporting specific properties by this order to be virtual, so that they are redefined in the derived classes. These derived classes are then used to display data in the journal. In that case, all should be displayed correctly. If there is a property not supported by the order, it is not displayed in the journal, since the Print(const bool full_prop=false) method of the COrder class has the default flag for disabling a display of unsupported properties in the journal, while the SupportProperty() virtual methods of the class simply return 'true' for any property.
What's next?
The first (and the smallest) part is ready. We have developed a basic object for the collection of history orders and deals as well as for the collection of market orders and positions. So far there is no practical value but this is only the beginning. This single basic object is to become a keystone for the system storing and displaying data on the order system. Our next step is to develop other necessary objects and collections using the same principles. I am also going to automate collection of constantly required data.
Author: Artyom Trishkin