Questions on MQL5 Wizard and standard library of trading classes - page 11

New comment
 
Reshetov:

Three questions:

  1. How to make the signal module work only on opening prices and not on every tick?
  2. How do I get the voting values of the signal module in the position tracking module? You need to trawl on an already calculated signal and not make up another signal module to follow.
  3. How to get the voting values of the alarm module in the money and risk management module? You need to open volumes according to the already calculated trading signals, not to compose another signal module for volume calculation.

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 answer all your own questions: "... 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. The Standard Library classes are not a dogma, but an attempt to provide a set of typical (in my opinion) solutions. Inherit (for use in the Wizard), overload methods, add your own. And you will be "happy"...
 
uncleVic:
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.

 
Reshetov:

It's a shame that such a good endeavour is abandoned to a distant corner.

Let's hope it's not abandoned, but shelved. I myself have many interesting thoughts on the development of the Master. But...
 
uncleVic:
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.

 
Reshetov:

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.

 
uncleVic:

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.

 
Reshetov:

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:

  • replacing the inclusion is no problem;
  • the main signal is intentionally created outside (for convenience of substitution);
  • add some ints and setting method calls?
 
uncleVic:

That's the way it was intended. The master creates the advisor's 'fish'. Next:

  • replacing the inline is no problem;
  • the main signal is intentionally created outside (for ease of substitution);
  • add some intuts and setting method calls?


That's the ugly thing about it, things like:

  1. Access to the methods of classes of modules included in the trading system is denied even for reading, which completely rules out the possibility of coordinating their work.
  2. The signal modules may easily conflict with position tracking modules, because they have different signals, and therefore incompatibility cannot be excluded.
  3. Different signals in modules, and therefore they all have separate settings, which results in not a few, but many input settings for an EA. The more different settings, the higher the probability of fitting to the history.
  4. After the operation of the wizard it's sometimes necessary to go through the sources in order to fix the problems. For the end user who is not familiar with programming it is not suitable at all, because he or she needs plug-and-play. Such confusions also create problems for a programmer, because it is much easier to work with own code than with code stacked with a wizard. An additional difficulty is that classes are inherited, i.e., the cause of misunderstanding can rarely be found at the level of descendants, but one has to look deeper into parent classes.

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...

 
Reshetov:

That's the problem, because from the beginning there are things that were not considered:

  1. Access to the methods of classes of modules included in the trading system is denied even for reading, which completely rules out the possibility of coordinating their work.
  2. The signal modules may easily conflict with position tracking modules, because they have different signals and therefore incompatibility cannot be excluded.
  3. Different signals in the modules, and therefore they all have separate settings, which results in not a few, but many input settings for the EA. The more different settings, the higher the probability of fitting to the history.
  4. After the operation of the wizard it's sometimes necessary to go through the sources in order to fix the problems. For the end user who is not familiar with programming it is not suitable at all, because he or she needs plug-and-play. Such confusions also create problems for a programmer, because it is much easier to work with own code than with code stacked with a wizard. An additional difficulty is that classes are inherited, i.e., the cause of misunderstanding can rarely be found at the level of descendants, but one has to look deeper into parent classes.

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.

Give us your specific suggestions. We will consider them.
 
uncleVic:
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

  1. Allocate some fields in CExpertMoney and CExpertTrailing classes to store an instance of CExpertSignal, i.e. the main module of signals.
  2. An instance of CExpertSignal, i.e. the signals module, should be passed to the position management and capital and risk management modules during the initialization of instances of these modules and stored in the specified fields in step 1. Obviously, before doing this, we should also check (make sure) that there already is an instance of the signal module class, i.e. that it was created.
  3. Create in CExpertMoney and CExpertTrailing classes additional methods, with identifier double getMainSingnal(), that address to an instance of signals module class, stored in the corresponding fields of these classes and return the result of signals module Direction() method.

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
1...456789101112131415
New comment
Reason: