My approach. The core is the engine. - page 146
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
Реter Konow:
...
It's not a bad idea.
But, what does it give us?
Maybe 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.
In MT5 the charts can be detached. And then you have to come up with the concept all over again.
Each EA has its own copy of the parameter kernel. It can be temporarily disconnected from the common GUI and another EA can be connected to the engine. It is important that they are copies of the same EA.
However, there are some difficulties, which I myself have not yet understood in full.
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.
Let the EA copies tell the engine their address with frequency. A short string. The engine will react and "talk" to the copy that has the same address as its current one. The standard exchange will take place. If address changes in engine, it starts "exchanging" with the copy that sets matching address. To standard exchange to 'ether' adds advisors or indicators to expose its short address. Several bytes. And function "listen to engine addresses starts when user pressed "reconfigure" button on engine GUI. Maybe it's something like this.
In MT5 you can detach the charts. And then you have to come up with the concept all over again.
I'm just not aware of it. The chart is detached purely "territorially", it becomes free from the coordinates of the main terminal window? In the exchange flows with the terminal, is it still connected in full?
I'm just not aware of it. The chart is detached purely "territorially", it becomes free from the coordinates of the main terminal window? And in the exchange flows with the terminal, it is still connected to the terminal in full?
The chart is detached, but it doesn't change the essence. (They are making a mess for nothing). There is no point in making copies of the GUI for each copy of the EA. Not that I can see, anyway. But it would be great to move one GUI between charts of copies.
If there is an EA copy control centre chart with the engine and the main GUI located on it, it would be handy.
The GUI of the EA should be made with the expectation that the EA will have many copies placed on different instruments.
SZY. The chart remains in the same window, only the window itself can be "taken out", from the terminal.
Let the copies of the advisers tell the engine their address with frequency. A short string. The engine will react and "talk" to the copy that has the same address as its current one. The standard exchange will take place. If address changes in engine, it starts "exchanging" with the copy that sets matching address. To standard exchange to 'ether' adds advisors or indicators to expose its short address. Several bytes. And function "listen to engine addresses starts when user pressed "reconfigure" button on engine GUI. Maybe it goes something like this.
You see the essence correctly. Only the details are not exact.
Switching the "communication" itself, is not a problem. But, when switching, you have to re-initialize the whole GUI. After all, in windows and elements of different copies, different values. So, it is necessary to redraw almost everything.
The parameter values of each copy are stored in the Parameter Kernel. This is an array. As long as the copy is disconnected from the engine, changes of values will only occur in the Expert Advisor's copy of the parameter kernel. As soon as the engine is connected, everything must be transferred to it from this kernel. Synchronise copies of the Parameter Kernel in the Engine and the connected Expert Advisor. So, you need to transfer a large amount of information (Parameter Core), and redraw the windows. After that, it will be possible to adjust the connected Expert Advisor and others will go into independent mode. Then connection will be made with them and the same thing will happen.
It will be like this. However, there are a lot of technical nuances.
Peter. With a period of N ms the EA receives something from the engine, and after that it passes its prepared something to the engine. The advisor then waits for the tick to arrive or a new batch of interrogation-exchange. Right?
Almost right. Communication and waiting for the tic, or other events, to happen asynchronously.
The timetable is detached, but it doesn't change the point. It's a waste of time).
...
SZY. The chart remains in the same window, only the window itself can be "taken out", from the Terminal.
And according to your conception that only one current chart is visible at a time anyway, and only it can be updated, will be broken - there will be as many charts visible as they are detached.
Certainly not a nightmare, but not good either - only one of the visible charts will "live", and the rest?
Do you think this is normal? Well if so, once again I am convinced of the lack of seriousness in solving bugs - if there is one, it is not to fix it, but to hide it.
Almost right. Communicating and waiting for a tick, or other events, happens asynchronously.
How about this. Advisors, each with frequent some (OnTimer), send to the engine its code string. All code lines are different. The engine internally analyzes incoming strings and "recognizes" one, for example from Expert Advisor number 3. In response to this EA, it sends a "signal" to start the main transmission. The engine works with this Expert Advisor.
If a person presses the "Switch" button, the engine will analyze allowed Advisors, and they are indexed, under numbers. Tells the current EA to switch to the state of setting an address, as if turning it off from the workflow, selects a code string with the index by 1 more and waits for the arrival of the same code string from any other EA. When the address matches, it sends a signal to this Expert Advisor to stop exposing the address and start the exchange. The only Expert Advisor and copy series, which is not in billing mode, will receive the exchange. In short, something like.
If the engine receives an address, it does a timeout to prohibit receiving addresses. So that the addresses do not overlap.
How about this. The Expert Advisors, each with a frequency of some kind (OnTimer), sends to the engine its own code string. All code lines are different. The engine internally analyzes incoming strings and "recognizes" one, for example from Expert Advisor number 3. In response to this EA, it sends a "signal" to start the main transmission. The engine works with this Expert Advisor.
If a person presses the Switch button, the engine will analyze allowed Advisors, and they are indexed, under numbers. Tells the current EA to switch to the state of setting an address, as if turning it off from the workflow, it selects a code string with index 1 more and waits for the arrival of the same code string from some EA. When the address matches, it sends a signal to this Expert Advisor to stop exposing the address and start the exchange. The only Expert Advisor and copy series, which is not in billing mode, will receive the exchange. In short, something like.
If the engine receives an address, it will time out the address inhibit. So that the addresses don't overlap.
This is not the right approach. Let me explain:
Each copy of EA does not stop writing its messages to the engine to its own separate resource. At the same time, each copy of the EA initializes values of its own elements in its copy of the kernel parameters. That is, even when disconnected from the engine, all copies of the EA should work properly.
When the engine switches connections between the copies of the EA, it must synchronize its kernel parameters with the kernel of the connected EA. After that, redraw the elements in the windows, so they display the actual information.
As for the communication with the selected Expert Advisor, everything is simple. The resource for receiving messages from the engine (as well as the resource of messages for the engine), each EA will have its own. That is, the engine will simply record its messages in the other resource, and read messages from the other resource. That resource belongs to the connected EA.