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
Three questions:
Theoretically, we can of course build the EA using the wizard and then add all these features manually to the code. But it is desirable that all this was implemented in the form of standard methods, i.e. for dummies who want to use the wizard, so that they don't have to get into the code and edit, for example, in case they want to replace one signal module with another.
You have answered all your questions yourself: "... ...build the EA with the help of a wizard and then... manually ...". There are no other options yet. The wizard, most likely, will not be developed in the near future.
It is a pity that such a good undertaking is abandoned in a distant corner.
If it had been brought up to date, a lot could have been done, i.e. we could have created ready modules from which dummies and other users could assemble various ready-made EAs without having to go through codes. But in this case we get the same mess as with algorithmic mql4, i.e. you take an algorithm, get into the code and use it manually. Again, the OOP principle is violated. For instance, if you want to replace one module with another, you'll have to get back into the code and change everything manually all over again. You get a lot of nonsense, because only "crawling" through the codes, in order to at least understand where and what to modify, would kill a lot of time.
It was a good start. Pity. I have just created a signal module yesterday, but I am still puzzled how to make the entire EA work without going to the source code every time. I wanted to write an article on how to use it. I have just inserted the module, added position management, money management and risk management, and everything works. But no, it won't work. If a user builds an EA using the wizard, it won't work. He will have to write a whole reams of instructions where to look in the code and what to change. Not to mention that I still have to deal with all this myself before writing an instruction.
So now there is nothing left for users but to learn mql5, OpenCL, etc. to deal with autotrading. Otherwise they will not have any luck.
Well, since this project has been abandoned, I will now think in a different direction.
It's a shame that such a good endeavour is abandoned to a distant corner.
Let's hope it is not abandoned but postponed. I have a lot of interesting thoughts myself on the development of the Wizard. But...
Hope dies last (c) popular proverb
To the first question, i.e. how to test the signal module by opening prices and trade by ticks, I found a solution so that I don't have to go into the codes, and even better than the generally accepted one.
I have not yet figured out how to read the indications of the signal module in position management and equity and risk management modules. I searched the source code and did my homework. The signal module obtains its results through the direction() method, i.e. I need only to address an instance of this very module class in the position management and equity and risk management modules and call this very method to read its values. How this can be done without changing the code, is not clear yet.
Hope springs eternal (c) popular proverb
To the first question, i.e. how to test the signal module by opening prices and trade by ticks, I found a solution so that I don't have to go into the codes, and even better than the generally accepted one.
And I cannot figure out how to read indications of the signal module in position management and equity and risk management modules, without digging the codes. I searched the source code and looked around. The signal module obtains its results through the direction() method, i.e. I need only to address an instance of this very module class in the position management and equity and risk management modules and call this very method to read its values. How this can be done without changing the code, is not clear yet.
Without changing the codes it probably won't work.
Not changing the codes probably won't work.
All is not lost yet. You can create classes inherited from CExpert, CExpertMoneu and CExpertTrailing and add to them the necessary methods to access an instance of the signal module class. But there is an issue here, too, as the wizard writes in the created EA #include <Expert\Expert.mqh> and not its descendant.
We have yet to think about it.
If developers had guessed right away that one signal module can be used for all other modules as the main one and additional signals (as in this version of the wizard) can be added to position support and equity and risk management modules and the codes would have been easier. But in our case, each module requires specifying additional conditions for signals and therefore they need additional external settings, which results in such a monster with a lot of parameters to be optimized. Not to mention that signals from one module can conflict, i.e. a signal module can open a position and an attendant module - close it on the next tick, if market entry and exit conditions are contradictory.
All is not lost yet. After all, you can create classes inherited from CExpert, CExpertMoneu and CExpertTrailing and add to them the necessary methods of access to an instance of the signal module class. But there is an issue here, too, as the wizard writes in the created EA #include <Expert\Expert.mqh> and not its descendant.
We have yet to think about it.
If developers had guessed right away that one signal module can be used for all other modules as the main one and additional signals (as in this version of the wizard) can be added to position support and equity and risk management modules and the codes would have been easier. But in our case, each module requires specifying additional conditions for signals and therefore they need additional external settings, which results in such a monster with a lot of parameters to be optimized. Not mentioning the fact that signals from one module can conflict, i.e. a signal module can open a position and an attendant module - close it on the next tick, if market entry and exit conditions are contradictory.
That's how it's designed. The wizard creates the "fish" of the EA. Further:
That's the way it was intended. The master creates the advisor's 'fish'. Next:
That's the ugly thing about it, things like:
We wanted the best. It turns out to be the same as always (c) Chernomyrdin
In general, most of the misunderstandings can be fixed, but this must be done at the root parent class level and then the fixed classes can be distributed through platform updates. I.e. you need to open access to Direction() method of the signal module from the position support and equity and risk management modules. Because if individual module developers edit the source code of parent classes, the resulting incompatibility of source code will be incompatible and the created modules will not work on other computers. If developers of modules create parent classes with overridden methods, the incompatibility will still be at master level, because the latter writes its own inludes, and, consequently, end-users need to write instructions again, and they will hardly want to get into sources, and if they do, then error in one single symbol or somewhere else, etc...
That's the problem, because from the beginning there are things that were not considered:
We wanted the best. It turns out to be the same as always (c) Chernomyrdin
In general, most of the misunderstandings can be fixed, but it is desirable to do it at the root parent class level and then distribute fixed classes through updates. Because if parent classes source code is corrected by module developers, the resulting incompatibility of source code will be incompatible and created modules will not work on other computers. If developer creates parent classes with overridden methods, then incompatibility is already at master level, because he writes his own inclusions, and therefore again need to write instructions to end users, and they are unlikely to want to get into the source code, and if they get in, then error in a single character or somewhere else, and so on and so forth.
Let us provide you with some suggestions. We will review them.
So far, there is only one single thing that addresses the above disadvantages:
Open access to reading the values returned by the Direction() method of the signal module from the position management and capital and risk management modules.
Add one more method, for example identifier double getMainSingnal(), that calls an instance of the signals module class and returns the result of Direction() method of the signal module. Since this information exchange takes place in read-only mode, the security won't be broken in any way.
To do this
P.S. The CExpert class has a reference to an instance of the signal module class.
CExpertSignal *m_signal; // trading signals object
You have to create analogous fields for CExpertMoney and CExpertTrailing classes and pass them the same value from the aforementioned field into CExpert class during initialization