My approach. The core is the engine. - page 145
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
I assume that every flow to and from the engine should have some kind of flow trait, a kind of magic number, and a flow trait that works with the tester (it is invariably unique). The engine reacts to the currently set flow and the Expert Advisors, indicators react to their attribute (Pseudo-magic number) of the infostream.
Everything works fine in the tester now, I am controlling the Expert Advisor in the tester from another window. It is in the simulator mode.
At present, the messages between the EA and the engine are not bound to a certain mage or name of the EA. It means that if the engine writes information into a resource, it will be read by any Expert Advisor that has been set up for communication. In order to separate the communication flows, each EA has to define a special label in the message header. And then, either read and follow the instructions or ignore them. There should be a separate label for Expert Advisors in the tester.
But here we see the need for a universal GUI for the engine through which we can configure and switch communications. Also to receive information about the Expert Advisors.
So, we have to change the concept of EAs. To be more precise, we have to upgrade it.
Here's the snag.
We have to have either a custom GUI for each EA or a common GUI for all of them. If it is common, then it should be invariant. It has to be well thought out in advance. Each Expert Advisor (even without the GUI), must have internal levers that it will provide to the engine.
Something to think about...
But here we come to the need for a universal GUI for the engine, through which to configure and switch communication. Also, to receive information about EAs.
There simply needs to be a necessary and sufficient permanently designed and configured administrative part in the engine, which deals with the administration of the control and the most varied custom part, built according to the customer's project.
There simply needs to be a necessary and sufficient permanently designed and configured administrative part in the engine, which deals with the administration of the management and a wide variety of customised parts, built according to the customer's project.
This administrative part is not comprehensible. What is it supposed to be?
If the engine works with one Expert Advisor, that's one thing. And if it works with several different ones, that's another thing.
There is still a lack of a conceptual framework...
This is the administrative part that is unclear. What should it be?
If the engine works with one EA, that's one thing. If it works with several different ones, that's another.
So far, there is a lack of conceptual framework...
Let's say something like this.
And in the EA or indicator in the start settings, the same field "Object 1", etc.
Suppose something like this.
And in the EA or indicator in the start settings the same field "Object 1", etc.
I wonder. Do you mean that we should switch the connection with these buttons? But, in this case, all Expert Advisors must be copies of one EA running on different pairs.
And what if the Expert Advisors are different?
Let's say something like this.
And in the EA or indicator in the start settings the same field "Object 1", etc.
I will implement it first. With one EA on different pairs. And then I will figure out how to deal with different EAs.
By the way, here's a good demonstration of working with the constructor. Dynamic, without words, and to music. :)
CREATING VISUAL STUDIO
https://www.mql5.com/ru/blogs/post/712102
By the way, here's a good demonstration of working with the constructor. Dynamic, without words, and to music. :)
VISUAL STUDIO
Original.
Let's say something like this.
And in the EA or indicator in the start settings the same field "Object 1", etc.
These are marked as connected to the control. And there is only one object that is controlled. So there is a toggle switch somewhere with a large indication.
These are marked as connected to the control. But there is one control that is specifically controlled. So there is a toggle switch somewhere with a large indication.
Each EA has its own copy of the parameter kernel. It can be temporarily disconnected from the common GUI and connected to the engine by another EA. It is important that they are copies of the same EA.
However, there are some difficulties here that I do not fully understand myself.
In theory, the question sounds like this:
Why do we need to add an engine with GUI for each chart of an EA copy if we can make one engine with the common GUI and connect it to all copies of the EA?
In practice, we will encounter some technical difficulties.
The Expert Advisor copy can write new values to its copy of the parameter kernel. If one of copies does not connect to the engine, the kernel will only change on the side of the copy. So, when reconnecting, we have to pass the entire kernel to the engine and the engine will redraw all elements in all windows where required. This is possible in principle.
Or redo the parameter kernel itself by making it a resource. In that case, the engine will get all the changes at once and just redraw the elements. This is not a bad idea.
But, what does it give us?
Perhaps we reduce CPU load, free up threads. If we have 10 copies of EA running on 10 pairs and we load each engine with GUI, the total CPU load may be too much. Because every GUI requires redrawing of elements which is a heavy load on CPU. But in fact we can see only one concrete GUI of one copy. The others are hidden.
So it's probably the right way to go. Make a common engine.