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

[Victor Kirillin]

Reshetov:

So far, there is only one single solution to address 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, with identifier double getMainSingnal(), that refers to an instance of the signals module class and returns the result of the Direction() method of the signal module. Since this information exchange is in read-only mode, the security will not be compromised in any way.

To do this

1. Allocate fields in CExpertMoney and CExpertTrailing classes to store an instance of CExpertSignal class, i.e. the main module of signals.
2. This very CExpertSignal class instance, i.e. the signal module, should be passed to the position management and money management modules during initialization of instances of these modules classes and saved in the fields specified in step 1. Obviously, before doing that, you should check (make sure) that there already is an instance of the signal module class, i.e. it was created.
   
3. Create in CExpertMoney and CExpertTrailing classes additional methods, with identifier double getMainSignal(), which refers to the signals module class instance, stored in the appropriate fields of these classes and returns as a result, the result of signals module Direction() method.

Almost everything is clear. The only thing I want to clarify: "why this desire of yours to see the signal at the MM and trailing level must be implemented at the base class level?

I don't think that would be a good thing (i.e. bad). The algorithm is not typical (from my point of view). As I understand it, you have your own MM and trailing modules (with their own algorithms tied to the signal).

Here and put in them corresponding 1.,2.,3.

[Yury Reshetov]

uncleVic:

Almost everything is clear. The only thing I would like to clarify is "why should this desire of yours to see the signal at MM and trailing level be implemented at base class level?".

I don't think that would be a good thing (i.e. bad). The algorithm is not typical (from my point of view). As I understood you have your own modules of MM and trailing (with your own algorithms linked to the signal).

So, put the appropriate 1, 2, 3 in them.

The point is that Master takes class SEhregt as a base. And consequently, I can't override necessary functions in modules I create, because they are already incompatible with this very basic CEhregt class from the very beginning because they don't have access to an instance of signals module class.

Because the instance of signal module class is stored only in the field of SEhregt class in Expert.mqh file, line 67

CExpertSignal    *m_signal;                   // trading signals object

and this field is not shared (inaccessible) with other classes and modules created from them.

For this very reason, there is no way I can override CExpertMoney and CExpertTrailing classes to make them compatible with the wizard.

After all, if access is denied in parent classes, the descendants won't get it in any way.

Get to the root (c) "Aphorisms" by Kozma Prutkov

[Yury Reshetov]

I figured out how to pass trading signals from the signal module to the position maintenance and money and risk management modules without passing instances of CExpertSignal.

Let's add two lines each to the CExpertMoney and CExpertTrailing classes:

  double m_signaldirection; // Direction from signals module
 
  void              setSignalDirection(double value)  { m_signaldirection = value; }
  

For the ExpertMoney.mqh file:

class CExpertMoney : public CExpertBase
  {
protected:
   //--- Direction from signals module  
   double m_signaldirection;
   //--- input parameters
   double            m_percent;

public:
                     CExpertMoney();
   void              setSignalDirection(double value) { m_signaldirection = value; }        
   //--- methods of setting adjustable parameters
   void              Percent(double percent)    { m_percent=percent; }
   //--- method of verification of settings
   virtual bool      ValidationSettings();
   //---
   virtual double    CheckOpenLong(double price,double sl);
   virtual double    CheckOpenShort(double price,double sl);
   virtual double    CheckReverse(CPositionInfo* position,double sl);
   virtual double    CheckClose(CPositionInfo* position);
  };

For the ExpertTrailing.mqh file:

class CExpertTrailing : public CExpertBase
  {
protected:
   
    //--- Direction from signals module
   double m_signaldirection;
public:
   //---
   void              setSignalDirection(double value) { m_signaldirection = value; }        
   virtual bool      CheckTrailingStopLong(CPositionInfo *position,double& sl,double& tp)  { return(false); }
   virtual bool      CheckTrailingStopShort(CPositionInfo *position,double& sl,double& tp) { return(false); }
  };

By doing this we have defined the necessary fields and methods to pass the trading signals. Now we need to pass these trading signals to the module classes. We will do it in Expert.mqh, i.e. for CExpert class

We will write one line to pass our trading signals to the positions support class

m_trailing.setSignalDirection(m_signal.Direction());

and insert it at the very beginning of method, which is called before every trailing stop, i.e. CheckTrailingStop():

bool CExpert::CheckTrailingStop()
  {
//--- Set signal direction to trailing stops module
   m_trailing.setSignalDirection(m_signal.Direction()); 
//--- position must be selected before call
   if(m_position.PositionType()==POSITION_TYPE_BUY)
     {
      //--- check the possibility of modifying the long position
      if(CheckTrailingStopLong()) return(true);
     }
   else
     {
      //--- check the possibility of modifying the short position
      if(CheckTrailingStopShort()) return(true);
     }
//--- return without operations
   return(false);
  }

We will write one line to pass trading signals into the money and risk management class:

m_money.setSignalDirection(m_signal.Direction());

and insert it at the very beginning of method, that is called before each position opening, i.e. CheckOpen():

bool CExpert::CheckOpen()
  {
//--- set signal direction to money management module
   m_money.setSignalDirection(m_signal.Direction());
   if(CheckOpenLong())  return(true);
   if(CheckOpenShort()) return(true);
//--- return without operations
   return(false);
  }

And that's it, the problem is solved.

Now, we can get the current value of trading signals in the position management and equity and risk management modules by accessing the value of m_signaldirection field. All we have to do now is to register the new fields and methods in CExpertMoney and CExpertTrailing classes in the documentation and add the modified files to the updates.

[Victor Kirillin]

Here are the files. In the Expert, lines 100 and 123 are handwritten.

If you have any more questions, please do not hesitate to ask.

[Yury Reshetov]

uncleVic:

Here are the files. In the Expert, lines 100 and 123 are handwritten.

If you have any more questions, feel free to contact me.

What kind of people are these developers? When will they start listening to what traders, who already have experience in creating trading systems, need instead of coming up with their own vision of designing trading systems that are practically unusable to end users because they need to manually tweak the source code? How many times must I explain that I can manually climb in and fix the source code, and even then it will take me a long time to understand what's what, even though I am familiar with programming. And the end user is unlikely to get into the code, because he does not understand programming. You yourself declared, and I quote:

"Knowledge of programming languages is no longer a prerequisite for creating trading robots."See https://www.mql5.com/ru/articles/240.

"The first version of the MQL5 Wizard already had the possibility to quickly create a ready to use Expert Advisor as a set of simple modules in the form of a source code in MQL5. You even didn't need to know MQL5- you just needed to read"Build your own Expert Advisor in MQL5 Wizard" (see https://www.mql5.com/ru/articles/275).

Now it turns out that knowledge of programming languages is required, as the user has to enter the code after the Wizard and edit something there. I.e. all previous declarations are inventions and deceit of developers.

For example, if I write my own money and risk management module that must open a position according to the level of trade signal issued by a module written by another developer of modules. As the result my module will be incompatible with the wizard. How to explain to users that they have to go somewhere in the code and insert some strings to make the module work? After all, module developers should create modules, and wizard should automatically combine them into one consistent system, so that modules, at a minimum, don't conflict with each other and are fully compatible with each other. But in your case, the wizard doesn't do it, because after the wizard, you have to go into code and redo everything manually.

Is it really so hard to put just six lines into parent class files, which I pointed out in my previous post? And the problem will be solved by itself and nobody will have to get into sources and change something there. What will your hands fall off? Why waste your time on some gibberish with demonstration of how manually something must be corrected after the wizard? Can't you spend this same time on a more useful task, so that nobody would have to get into the code to solve similar problems later?

What is the ideology of your company - on the one hand it declares complete automation, but when it comes to it, they propose to get into the code and redo everything by hand after the so-called "automation"?

All in all, as I understand it, it is useless to explain all this. You should not be surprised that traders do not want to switch to MT5 because the platform is crude and developed not for the convenience of autotrading, but for the convenience of the developers of that very platform. And unless the user thoroughly learns programming, he had better stay away from automated trading.

If you don't want to, you don't have to. If you have nothing else to do, then sit here and explain to each user where and how they need to get into the source code with their hands and what exactly to fix.

[Renat Fatkhullin]

I am afraid you are either in the grip of maximalism or simply do not understand the limits of the tools' applicability.

In any case, with this level of argumentation and taking almost every issue beyond the limits of exaggeration, there can be no work with you. Real work involves conscious decision-making, not verbal demagoguery.

[Yury Reshetov]

Renat:
I'm afraid you are either in the grip of maximalism or simply do not understand the limits of applicability of tools.

In any case, with this level of argumentation and taking almost every question beyond the limits of exaggeration, there can be no work with you. Real work implies conscious decision-making, not verbal demagoguery.

In general I did not ask for work, i.e. to earn money, and I was quite happy to cooperate on a voluntary basis. How and where I earn my living I decide.

Well, it won't and it doesn't have to. Our business is to offer, you have the right to refuse. As they say: the master is the boss.

If your company has already understood everything and even taught dummies to create so-called "ready-made" Expert Advisors. Moreover, the point is that they are only good for demonstration of Wizard, but they are not very good for automated trading, because even on historical data the equity curve looks inconvenient as the modularity is implemented, but the modules consistency for a complete trading system is missing.

Good luck!

[Mykola Demko]

Reshetov:
...

For example, if I write my own money and risk management module, which should open a position according to the level of the trading signal issued by the module written by another module developer. The result will be that my module is already incompatible with the wizard. How to explain to users that they have to go somewhere in the code and insert some strings to make the module work? After all, module developers should create modules, and wizard should automatically combine them into one consistent system, so that modules, at a minimum, don't conflict with each other and are fully compatible with each other. And you have a wizard that doesn't do it, because after him you have to go into code and redo everything manually.

Is it really so hard to write just six lines into parent class files, which I pointed out in my previous post? And the problem will be solved by itself and nobody will have to go into sources and change something there. What will your hands fall off? Why waste your time on some gibberish, demonstrating how to manually fix something after the wizard? Can't you spend this same time on something more useful, so that nobody would have to get into code later to solve similar problems?

...

Your approach violates class encapsulation, and as a result brings hierarchical confusion.

Read Steve McConell's book "The Perfect Code" at your leisure.

Imagine as a factory for the production of gloves, there is a five-fingered stamp for the right and left hand, but then comes a small order for six-fingered gloves. There are people like that, after all. But instead of making a stamp for them (which will make a batch and stay there for a while), you suggest modifying the five-toed stamp by making a sliding finger. It seems to be universal and everything is great, but the strength of the five-toed stamp will be weakened for the sake of universality (for the sake of a tiny need to occasionally produce six-toed gloves). And then a batch of 300 four-fingers will be ordered, and again crumble the well-proven, reliable template.

You've been told above:

"why is it your desire to see the signal at the MM and trailing level needs to be implemented at the base class level?".

I don't think it would be good (i.e. bad). The algorithm is not typical (from my point of view). As I understand it, you have your own MM and trailing modules (with their own algorithms tied to the signal).

Instead of changes to the standard bible, it would be better to make developments to extend it (through inheritance). Then it would be really interesting.

HZZ Moreover, so that people don't have to deal with the intricacies of code (as you wrote above), you can wrap the ready modules in biblio and sharovariously pour into the market, then just plug the module from Reshetov and press [download dough] button.

[Yury Reshetov]

Urain:

Your approach violates encapsulation of classes, and as a result introduces hierarchical confusion.

Read Steve McConell's book "Perfect Code" at your leisure.

Simply put, think of the Master as a glove factory, there is a five-fingered stamp for the right and left hand, but then a small order comes in for six-fingered gloves. After all, there are people like that. But instead of making a stamp for them (which will make a batch and stay there for a while), you suggest modifying the five-toed stamp by making a sliding finger. It seems to be universal and everything is great, but the strength of the five-toed stamp will be weakened for the sake of universality (for the sake of a tiny need to occasionally produce six-toed gloves). And then a batch of 300 four-fingers will be ordered, and again crumble the well-proven, reliable template.

You've been told above:

Instead of making changes to the standard bible, it would be better to make developments to extend it (through inheritance). Then it will be really interesting.

How many times can we say that we cannot inherit what is not available in parent classes? When will you finally get acquainted with the book "Code Complete" written by Steve McConell himself?

1. My approach doesn't violate encapsulation principles, because in the version I proposed, everything superfluous is hidden, and modules are only given a trade signal as a value of type double and only in read mode. Unlike some people, I have not only read the books on OOP, but carefully studied them.
2. I haven't suggested creating six-fingered gloves to template ones, i.e. attaching the sixth fingers as additional modules, but merely suggested matching all existing modules with signals from signals module, which is actually the main one for trading systems because the entire system must operate by its command. It was you who suggested modularity, i.e. gloves with interchangeable fingers. But since you have made it so that the right hand is unaware of what the left hand is doing, i.e. other modules cannot get information from the signal module and synchronize their actions with it, the gloves will have fingers (modules) of different sizes, when the user puts the glove on his hand and sees that one of its fingers is small and does not fit into it, while the other is big and excessive.

For example, a trailing stop is executed according to a separate signal system developed by a third-party developer of the module, such as a moving wave or parabolic, whose signals at some points contradict the signals of the module and the trading system starts working inconsistently. The money and risk management module also cannot guess telepathically that the trading signal is weak and it is time to reduce the volume of open positions and act according to some rules independent of the signal module, i.e. one of them asks to slow down on corners and the other one gears up. And the entire trading system, created with the help of your so-called master, turns out like in Krylov's fable called "The crab and the pike". No more and no less. And this very fable ideology of assembling reckless advisers, your company is trying to impose on us for autotrading. Do we need it?

The result is trading systems with such charts of equity and balance that can only scare traders and investors alike, see https://www.mql5.com/ru/code/833.

This is not because the creator of the module, in this particular case Nikolay Kositsin, did something wrong but because the rest trading system modules cannot be coordinated with each other and are working inconsistently.

But it is useless to explain. The platform developers, instead of writing a miserable six lines to fix the problems, will write kilometres of footnotes in the forums, accusing the developers of trading systems to spread demagogy, encapsulation violations and other mortal sins, but they will not lift a finger to correct their own deficiencies and misunderstandings.

So there is no point in having further discussions. Stay with your opinion and do as you please. I'm sick of it and it is useless, because the platform developers do not give a damn, because they don't make their own stuff and whether these very tools can be used by the platform users for autotrading, the developers do not care. A man who is well fed does not know a hungry man.

[Mykola Demko]

Reshetov:
...

Reshetov, I don't even want to read your emotional scribblings. You want to argue, argue your case.

The point of a wizard is to create a template that meets most traders' needs. I have an EA template on cherver (I wrote it myself), it sets the basic functionality. And in practice it always has to be corrected. But the edits are minimal. If I had created a template not to edit it at all, it would have been a huge code for all occasions, in which one could get lost.

The wizard creates a template that is already working, and a person who does not know how to program can use it as it is. If you understand coding, it's easy to change it to what you want. It's enough just once to understand how things are created and where they are separated in the standard library. In addition, you can also use the standard library as a template and simply copy the sections you like into your own code.