Request to Author. Your approach is extremely convenient when writing TC. Everything superfluous is hidden from the eyes, which cannot but please. What is the payoff for this?
If I write an impulse-TC using the classical method and yours, how much slower will your method be in the tester?
There can be no doubt that your code will be more beautiful, concise, convenient and universal.
Do you already support multisymbol TCs (where is the multisymbol OnTick)?
//|Contener class for managing strategies of type CStrategy |
A typo.
It seemed to me shortsighted to define only CStrategyList::OnChartEvent, and then call only it in the native OnChartEvent.
I would have made a base class with a virtual OnChartEvent. And absolutely all classes CStrategyList, CStrategy and others (by the way, you don't inherit indicators from anything for some reason) would be derived from the base class. And in the native OnChartEvent, you should call once in a loop all virtual OnChartEvent that were created.
I see that you are using libraries written by developers. For example, Arrays. Are they written normally?
You have this everywhere in your source code
#include <Strategy\Message.mqh>
This assumes that I don't have a Strategy folder for other needs. Why don't you use inverted commas in includnics when it's allowed? And why not make
#include <Sokolov\Strategy\Message.mqh>
It seemed to me shortsighted to define only CStrategyList::OnChartEvent, and then call only it in the native OnChartEvent.
I would have made a base class with a virtual OnChartEvent. And absolutely all classes CStrategyList, CStrategy and others (by the way, you don't inherit indicators from anything for some reason) would be derived from the base class. And in the native OnChartEvent I would write one call in a loop of all virtual OnChartEvent that were created.
Yes, this is probably more correct. Now the OnChartEvent event is kind of ignored for experts. I will make appropriate changes in the next version.
I see that you use libraries written by developers. For example, Arrays. Are they well written?
Excellent and they are extremely optimised. Over the years of their use all the algorithms in them have been worked out and fine-tuned. That's why I recommend them.
You have it like this everywhere in the source code.
This assumes that I don't have Strategy folder for other needs. Why don't you use inverted commas in includnics when it is allowed? And why not make
Sources located inside the Strategy folder just locally refer to each other, maybe I've looked through something, I don't know, but there should be local references. Expert Advisor files and the Expert Advisor mq5 module itself refer to the engine globally, and this is also correct, as it is a module external to the library.
I looked at EventChartPBarChanged.mqh. Why is const ignored where it is required?
Request to Author. Your approach is extremely convenient when writing TC. Everything superfluous is hidden from the eyes, which cannot but please. What is the payoff for this?
If I write an impulse-TC using the classical method and yours, how much slower will your method be in the tester?
There can be no doubt that your code will be more beautiful, concise, convenient and universal.
Do you already support multisymbol TCs (where is the multisymbol OnTick)?
The main time in the strategy tester is spent on the work of its infrastructure (bar scrolling, emulation of the trading environment, etc.) Much less time is spent on the Expert Advisor code itself.
On the other hand, profiling has shown that the main resource-intensive methods of CSTartegy are BuyInit, SellInit, BuySupport and SellSupport methods - i.e. the Expert Advisor logic itself. All other strapping is successfully compiled into flat code in an optimal way, or simply cut out if it is not used. That's why high-level OOP programming is justified.
Note that in more or less complex Expert Advisors with many rules and heavy infrastructure, programming in an initially flat form (without functions and OOP) will lead to inevitable programmer's errors, and as a consequence the performance of such an Expert Advisor will be even less than with OOP. The times of assembler are over. The compiler has long ago defeated a human in certain areas of optimisation. It is left for a human to define an initially competent and scalable architecture with a minimum number of interfaces and good manageability.
.
Wouldn't it be better to add just one MqlTick?
The video in the article is not visible in any browser.
Interesting idea by the way. I didn't think of that for some reason.
There are problems with video. In the new version of the site refused to flash. Now only on yuteb you can watch videos. It will take some time to publish videos, but we will fix it soon.
The sources located inside the Strategy folder refer to each other locally, maybe I've looked through something, I don't know, but there should be local references. Expert Advisor files and the Expert Advisor mq5 module itself refer to the engine globally, and this is also correct, as it is a module external to the library.
Looked through. Look at MoneyManagment.mqh.
Global reference from mq5 - I completely understand the need. But you have reserved the Include/Stategy folder with your solutions. And I use this folder for my own needs. And I don't want to see other people's mqh in it. It would be logical if you moved all your infrastructure to Include\Sokolov/Strategy, Include\Sokolov/Strategy, Include\Sokolov/Panel, etc.

- 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 Universal Expert Advisor: Pending Orders and Hedging Support (Part 5) has been published:
This article provides further description of the CStrategy trading engine. By popular demand of users, we have added pending order support functions to the trading engine. Also, the latest version of the MetaTrader 5 now supports accounts with the hedging option. The same support has been added to CStrategy. The article provides a detailed description of algorithms for the use of pending orders, as well as of CStrategy operation principles on accounts with the hedging option enabled.
The set of CStrategy classes keeps actively improving. New algorithms are being added to the engine to make trading even more efficient and simple. Further algorithm development mainly stems from the feedback of users who read this series of articles and ask questions in the article discussion topics or by sending personal messages. One of the most frequent questions was about the use of pending orders. Well, pending orders were not discussed in the previous articles, while the CStrategy engine did not provide a convenient tool for working with pending orders. This article introduces significant additions to the CStrategy trading engines. After all these changes, CStrategy now provides new tools for working with pending orders.
We will create a strategy that will be based on entries during strong market movements in the direction of the movement, so it will be called CImpulse. At the opening of each new bar, the EA will measure a predefined distance from the current bar, expressed as a percentage. The EA will place pending BuyStop and SellStop orders at an equal distance from the current price. The distance is set as a percentage. If one of the orders trigger within one bar, it means that the price has moved quite a long distance, which indicates the market impulse. The order will be executed and will turn into an open position.
Open positions will be managed by a simple moving average. If the price returns to the Moving Average, the position will be closed. The screenshot below shows a typical entry into a long position upon triggering of a pending BuyStop order:
Fig. 1. A long position of the CImpulse strategy.
Author: Vasiliy Sokolov