Discussing the article: "Developing a multi-currency Expert Advisor (Part 4): Pending virtual orders and saving status"
Wouldn't use such an architecture.
Imagine that MQ made virtual commerce built into the language. Then you wouldn't get the idea of embedding other entities in it, because it simply can't be done through OOP inheritance - the sources aren't available. You would create a different architecture.
Graphical objects in a virtualisation - well that's all in the same pile again.
The architecture has become so unwieldy that it makes you feel uncomfortable. Instead of assembling from simple bricks, you decided to create universal bricks.
We're back to not really liking the implementation, but liking others (that aren't done but have been thought about) even less. Perhaps in the process of further development it will be possible to do it differently, but for now.
About the situation with inaccessible sources: in this implementation I decided just to take advantage of the fact that the sources are available and you can add something to them that was not necessary to add at once. I tried to make such additions minimal. The alternative was to create several new inheritor classes for the family of CVirtual* classes. This approach seemed even more cumbersome to me. But it is quite possible that we will come to it when there will be more classes and it will become ugly to store them in one folder.
I needed graphical objects to control the development of trading strategies, so they were implemented. And the CVirtualOrder class was not changed at all. But I had to add four new lines of code to the CVirtualReceiver class. I chose this option among different possible ones.
If there is no need in graphical display of virtual positions, you can either not use it or return to the library variant from the previous article.
We're back to not really liking the implementation, but liking others (that aren't done but have been thought about) even less. Perhaps in further development it will be possible to do things differently, but for now this is how it is.
Unfortunately, I don't have enough time to show my vision on the example of partial refactoring.
After the first launch, the Expert Advisor opens virtual and real positions, calculates, maybe, some indicators on price data. It is this information that makes up the state of the EA as a whole. If you now reload the terminal, the EA should not only recognise the open positions as its own, but also restore all its virtual positions and the necessary calculation values. If the information about open positions can be obtained from the terminal, the information about virtual positions and calculation values must be saved by the Expert Advisor itself.
Imagine that the Expert Advisor works on two trading accounts of one broker. One of the terminals is switched off. During this time, the virtual positions have changed in the running one. How to make the behaviour of the Expert Advisor coincide with the terminal that did not stop working?
How I do it. I do not save virtual positions at all. When starting the Expert Advisor, all internal TSs are launched in the virtual tester before the current TimeCurrent. Thus, we get that in the reloaded EA all the data at the current moment coincide with the version without reloading.
By "reloading" we also mean the situation when there is a pause in the work of the Expert Advisor. For example, a long OrderSend or reping. That's why we need to request price data from the moment of the last request. And run them in a virtual machine.
You already pay a lot of attention to reviewing other people's code, for which I thank you very much.
Imagine that an Expert Advisor works on two trading accounts of the same broker. One terminal is down. During this time, the virtual positions have changed in the running one. How can we make the behaviour of the Expert Advisor to match the terminal that did not stop working?
I have encountered such a situation, but it was an insignificant factor affecting the trading result. Besides, there were times when the terminal that "slept through" the closing of positions closed them at a more favourable price. Therefore, ensuring full identity was not an end in itself.
And if there are different brokers, even Expert Advisors working synchronously can show slightly different results due to small differences in quotes. Although one should strive for identity.
How I do it. I don't save virtual accounts at all. When launching an Expert Advisor, all internal TS are launched in the virtual tester before the current TimeCurrent. Thus, we get that in the reloaded EA all the data at the current moment coincide with the version without reloading.
This is an interesting approach, I have not considered this option before. If I understand it correctly, when using it, we must have a fixed date of the start of virtual trading, and it must be the same for different instances of Expert Advisors in different terminals. This is not difficult. And a virtual tester must be implemented or your ready-made one must be used. This is more complicated.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Check out the new article: Developing a multi-currency Expert Advisor (Part 4): Pending virtual orders and saving status.
Having started developing a multi-currency EA, we have already achieved some results and managed to carry out several code improvement iterations. However, our EA was unable to work with pending orders and resume operation after the terminal restart. Let's add these features.
In the previous article, we have significantly revised the code architecture to build a multi-currency EA with several parallel working strategies. Trying to achieve simplicity and clarity, we have so far only considered a certain minimum set of functionality. Even considering the limitations of our task, we have significantly altered the code from the previous articles.
Now hopefully we have the groundwork that is sufficient enough to increase functionality without radical changes to the already written code. We will try to make a minimum number of edits only where it is really necessary.
As a further development, we will try to do the following:
Let's start with the simplest thing - handling virtual pending orders.
Author: Yuriy Bykov