New article Universal Expert Advisor: the Event Model and Trading Strategy Prototype (Part 2) has been published:
This article continues the series of publications on a universal Expert Advisor model. This part describes in detail the original event model based on centralized data processing, and considers the structure of the CStrategy base class of the engine.
The article contains further description of the universal trading engine CStrategy. In the first article Universal Expert Advisor: Trading Modes of Strategies (Part 1),
we have discussed in detail trading modes and functions that allow
implementing them. We have analyzed a universal Expert Advisor scheme
consisting of four methods, two of which open new positions and the
other two methods close them. Different combinations of method calls
define a particular trading mode. For example, an Expert Advisor can be
allowed only to Sell or to Buy, can manage previously opened positions
or wait. Using these modes, an Expert Advisor operation can be flexibly
set up depending on the trading time or day of the week.
However, the trading modes are not the only thing that an Expert
Advisor may need. In the second part we will discuss the event model of
the CStrategy trading mode based on the centralized event handling. The
proposed event handling scheme differs from the system events in that
all the events are gathered in one place. The advantages of such an
implementation will be considered later.
Also, this article describes two important classes of the trading engine — CStrategy and CPosition.
The first one is the core of the whole EA trading logic, it unites
events and modes into a single flexible framework that the custom EA
inherits directly. The second class is the basis of universal trading
operations. It contains actions applied to an open position (like
closing of a position or modification of its Stop Loss or Take Profit).
This allows formalizing all trading actions and making them
When designing a trading system which analyzes multiple symbols, you
need to create a mechanism that can track changes in the prices of
multiple instruments. However, the standard OnTick
function is only called for a new tick of the instrument the Expert
Advisor is running on. On the other hand, trading system developers may
use the OnBookEvent function that responds to changes in the order book (Depth of Market). Unlike OnTick, OnBookEvent is called for any change in the order book of the instrument, to which you subscribed using the MarketBookAdd function.
Changes in the order book happen very often, that is why monitoring
this event is a resource-intensive procedure. As a rule, monitoring
changes in the tick stream of the required symbol is enough for Expert
Advisors. On the other hand, the event of the order book change also
includes the arrival of a new tick. Apart from OnBookEvent, you can set up calls of OnTimer at specified intervals and analyze price changes of multiple symbols in this function.
So in the system functions that react to NewTick, BookEvent and Timer events, you can add a call of some intermediate module
(let's call it EventProcessor), which would simultaneously analyze
changes in prices of multiple instruments and generate an appropriate
event. Each event would have a unified description in the form of a
structure and would be sent by the control methods of the strategy.
Having received an appropriate event as a structure, the strategy would
either react to it or ignore. In this case, the system function which
actually initiated the event for the final Expert Advisor would be
Indeed, if an Expert Advisor receives a notification of a new
incoming tick, it does not matter whether the information is received
through OnTick, OnTimer or OnBookEvent.
The only thing that matters is that there is a new tick for the
specified symbol. One event handler can be used for many strategies. For
example, if each strategy is represented as a custom class, multiple
instances of these classes can be stored in the special list of
strategies. In this case, any strategy from the list will be able to
receive a new event generated by EventProcessor. The following diagram
shows how events are generated and sent:
Fig. 1. Diagram of event generation and sending
Author: Vasiliy Sokolov
I tried to compile your code (Agent.mq5) and I got the following error. Build 1274
Internal compiler error Agent.mq5 1 1
There is also a little typo on line 388 of Dictionary.mqh
/| Returns previous object. The current object becomes previous|
On build 1241, the code is compiling well, so I tried to run a backtest. It doesn't take any trades.
After digging a bit I found it's due to filling mode. The mode allowed on the broker/symbol I am using is ORDER_FILLING_IOC. Your TradeCustom class set the filling mode by default to ORDER_FILLING_FOK. And I am stick there, how can change this filling mode for the Agent.mq5 EA to take trade ? I could search, it will take me a lot of time.
That's the problem with such tools, very similar to MQL5 wizard EA from Metaquotes, it's almost unusable for anyone who doesn't know all the details of the classes. Once you face an issue which was not provided by the author it becomes a real pain to fix it or modify/add to it. I don't see any real difference between your solution and the one from Metaquotes (wizard).
Anyway, congratulations for the huge work. It is a great programming work.