Discussion of article "Universal Expert Advisor: CUnIndicator and Use of Pending Orders (Part 9)" - page 4
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Of course, and naturally, I'm not surprised that the choice was made in favour of Vasily's work - it has a finished look, while my library is just being created. You misunderstand a bit the meaning and essence of my articles - they describe the process of creating a library, not the process of using an already finished one. Those who want to dive into the development and understand the principles - they do it, and ask questions, clarify and learn. Someone immediately understood what is written there and follows the development. But this is not the place to discuss it - this is the place to discuss Vasily's work.
And what makes you think that I, having started a huge work, would just abandon it overnight? Of course not. And there is a lot of potential for development.
I tried to use your library. It has a lot of useful functions, although it is not enough for trading itself. But I don't see any practical use for it - the speed of testing suffers greatly.
Good afternoon. Thank you for your feedback. The optimal solution is to put the UTE codes into a public version control system (Git or MT's). In this case, users will be able to fix errors and make additional changes/improvements to the code after my code review. I think this system of project development is optimal for open source, because nobody can carry everything alone.
As for the UTE itself, I think that its main functionality is formed. It covers most of the most common trading functions. Therefore, the development of UTE in the same direction will not give fundamentally new things. However, a functional framework for working with data can give a global impetus to the development of UTE. The idea is to operate with system structures in object style and work with collections (including system ones) in functional style. In this case, the clear distinction between system and user data types will be erased and queries for their processing will be created "on the fly" by users themselves (something like LINQ in C#). Unfortunately, language restrictions do not allow to write this framework on a one-two basis, so this is still just an idea.
And multisymbol strategies, I don't understand if it allows to create them? One strategy that works with 2 or more characters. Judging by the Strategy.mqh code, the working tool is always one.