My approach. The core is the engine. - page 139
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
Are you people all convincing Peter of the benefits of OOP?
You're wasting your breath.
You guys are right, I know all this and I understand it very well. But apparently Peter touches a mental chord of my OOP-soul with his "I do not want, I will not", so I'm constantly falling into these endless explanations, arguments and squabbles.
And the engine will load kernels from a text file. It's not hard to do.
Oh, I see. Yeah, that's better. So your kernel is a text file - essentially a group of settings for the engine.
No, Vasiliy, you tend to dramatise everything.))
There's a button in the builder that, when clicked, prints all the files.
And the engine will load kernels from a text file. It's not hard to do.
sorry to interrupt, but just wondering - how is the refactor supposed to be done ? e.g. change bad names or generally the composition/location of elements
Oh, I see. Yes, that's better. So your kernel is a text file - essentially a group of settings for the engine.
Yes. Exactly. All the information needed for the engine to reproduce a particular GUI and work with it. Right now I'm installing it directly to the engine, and then I'll make it loadable from the file that the builder prints.
sorry to interrupt, but just wondering - how is the refactor supposed to work ? e.g. change bad names or the composition/location of elements in general
This is all in the constructor. The KIB code is written and the file is recompiled.
Here's how to work with the constructorhttps://www.mql5.com/ru/blogs/post/717782
Or another example. Recently I've been asked to modify a procedural Expert Advisor so that it could trade simultaneously on several symbols (running on one chart). The procedural style would have required long and complex efforts to make it trade independently on different symbols at the same time. In contrast, I simply placed the entire procedural code in a class and created three exemplars. I specified an individual set of settings for each of them, including the work symbol, etc. The code worked properly on the first try. The code worked as it should have done on the first try. The user was satisfied.
I have had a similar example this week, I was asked to make an Expert Advisor that opens buy at the opening of a bar in one TF and opens sell at the opening of a bar in another one.)
But I rewrote a trivial function to define a new bar into a class, and created 2 instances of the class to define a new bar. I passed the timeframe of the TF as a parameter during the initialization of the constructor
5 minutes of work, but it is guaranteed that everything will work and there will be no confusion with the names of functions NewBar_TF1() , NewBar_TF2() .... just like it is convenient to initialize after changes of settings by user - delete the object in DeInit(), create the object in ONInit()
imho, OOP is convenient and practical
This is all in the constructor. The KIB code is written and the file is recompiled.
Here's how to work with the constructorhttps://www.mql5.com/ru/blogs/post/717782
Yes. Exactly...
That's why there's a lot of confusion with your engine with others. Give non-standard names to elements in your system. Not a kernel - but an autogenerated configuration file.
But it will overwrite all user edits that are in the events ?
Explain further.
That's why there's a lot of confusion with your engine and why others get confused. Give non-standard names to elements in your system. Not a kernel - but an autogenerated settings file.
So the file, is the printed kernels. There's more than one.