My approach. The core is the engine. - page 166
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
Peter, where is the proof?
I can provide you with proof of the low cost of data exchange between programs. Even when passing a string of thousands of characters. I've made an experiment. I'll find and upload two test EAs. Communication via resources does not load the processor, only redrawing.
The engine will accumulate a wide range of functionality, and only a small part - the user's GUI. That is, the engine will include code that will only partially be required by a separate application, and the rest of the code can be used by other applications on other graphics. In this way, the engine becomes an auxiliary functionality used by different EAs at the same time, and therefore, it should be a separate program running in its own thread.
Here. Put it on the first graph.
And this one is on the second.
I can provide proof of the low cost of exchanging data between programmes. Even when transferring a string of thousands of characters. I did an experiment. I'll find and upload two test EAs. Communication through resources does not load the processor, only redrawing.
The engine will accumulate a wide range of functionality, and only a small part - the user's GUI. That is, the engine will include code that will only partially be required by a separate application, and the rest of the code can be used by other applications on other graphics. In this way, the engine becomes an auxiliary functional centre used by different EAs at the same time, and therefore, it must be a separate programme.
But if your engine serves several applications, then it will slow down the whole process, because it will serve different programs sequentially, while instances of your engine class in each application will run in parallel.
The programs will access the engine asynchronously and as needed. One will request to build a graph based on the array passed to it, the other to calculate a value using a formula, the third something else... All of this will not be a single continuous process, but will occur from time to time.
In this case, the engine will carry the GUI of one of the applications, and the user will switch to the GUI of another application.
If you put the engine in an application, there is a lot of unnecessary stuff in the application. So, you need to customise the engine to the specific needs of the individual EA. The user will not be able to cope with this. It is long and complicated. And it will interfere with the development of the engine's universality.
Just a bunch of words without any meaning.
Just take my word for it. I know what I'm doing.
Just take my word for it. I know what I'm doing.