My approach. The core is the engine. - page 165

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 guess so. But if a GUI, that's another file, and that's not possible in the market.
Maybe . I don't know. But I think this issue is solvable if Peter has something of value.
You got it right, Nikolay. The Expert Advisor works without the engine. The engine creates the GUI of the EA as soon as the EA is placed on a separate chart and receives commands from it. The engine can switch between different EAs. When switching, it simply reloads the other core from a text file. It can be left in place altogether, but allocate a separate chart and keep it there at all times.
Under current rules, products with additional dependencies cannot be distributed via the marketplace. Furthermore, I suspect this is legally forbidden or rather difficult.
External ex* libraries cannot be used, including those that do not contain calls to the dll. However, indicators, such as Peter's engine, are not subject to this restriction.
External ex* libraries cannot be used, including those that do not contain calls to the dll. However, this limitation does not apply to indicators, such as Peter's engine.
I was specifically interested in this question by asking the service-desk marketplace. The answer was quite clear, though not very happy :-) the Market's product must be a thing-in-itself and not require installation of any other components. All necessary indicators and libraries should be crammed inside via Resources.
Which is logical - a person bought a product and the product (and all its claims) should be immediately available without extra work.
And there was no situation when some dependency was updated, but the Expert Advisor fell off :-)
And in general, trading is:
my income - "core - engine"
;)There's an idea to save the user from having to lug the kernel file everywhere so that the engine can upload it. When producing a GUI, the constructor produces a kernel file. Instead of saving to a file, the constructor can save the kernel to a resource and write a string to connect this resource in the kernel properties file. When the user connects the created Connexion Properties file, this resource with the kernel will be integrated when initializing their EA. Then, when connecting to the engine, the latter will simply read the resource with the kernel from the EA and play the GUI. Thus, there will be no need to drag the kernel files.
Oh, gosh, I thought it's implemented in your way. Of course, what's the point of carrying around your configuration files.
Can you describe it in more details? How, what and why.
...
Nikolai, if you're suggesting opening up the engine code for everyone to put it in the EA, then I've thought about it. Alas, that would put a limit on the development of the engine. Everything would happen in a single application thread, which would limit the resources used and most of the benefits that can be achieved by parallelising the computation would be lost. Additionally, the users will start to make changes to the engine and distribute modified versions, which will create chaos and new development problems.
Therefore, the idea is good in theory, but in practice, alas...(.
Nikolai, if you are suggesting opening up the engine code for everyone to put it in the EA, then I have thought about it. Alas, this would put a limit on the development of the engine. Everything would happen in a single application thread, which would limit the resources used and most of the benefits that can be achieved by parallelising the computation would be lost. Additionally, the users will start to make changes to the engine and distribute modified versions, which will create chaos and new development problems.
Therefore, the idea is good in theory, but in practice, alas...(.