Features of the mql5 language, subtleties and tricks - page 268

[fxsaber]

Vladimir Simakov #:

This is so that everyone can understand how it will be (click the copk after Calculated appears):

Why?! It's obvious that EventChartCustom is done after the calculations are released. You have Sleep as the final "calculations". So it should have been after it that the EventChartCustom should be done .

Actually, this is exactly what you have done through OOP. Initially, the demonstration was an approach for finalisation, built on your knees.

[fxsaber]

Forum on trading, automated trading systems and testing trading strategies

Peculiarities of mql5 language, subtleties and techniques of work

Vladimir Simakov, 2024.09.24 11:06 AM

It should be like this:

class EventLocker{
public:
   EventLocker(){
      m_lock = true;
   }
   ~EventLocker(){
      m_lock = EventChartCustom(0, 0, 0, 0, "");
   }
   static void Unlock() {m_lock = false;}
   static bool Locked() {return m_lock;}
private:
   static bool m_lock;
};

bool EventLocker::m_lock = false;

Such would add for reliability.

[Vladimir Simakov]

fxsaber #:

What the fuck?! It's obvious that EventChartCustom is done after the calculations are released. In your case, Sleep is the final "calculation". Therefore, it should be after it that EventChartCustom should be done .

Actually, this is exactly what you have done through OOP. Initially, the demonstration was an approach for finalisation, built on your knees.

Because the result will be like this:

class TComputer{
public:
   TComputer(int _init):m_init(_init){}
   ~TComputer(){
      EventChartCustom(0, 0, 0, 0, "Hello world!!!");
   }
   
   double Compute(){
      double Res = 0;
   
      for(int i = 0; i < m_init; i++)
         Res += MathSin(MathRand());
      return Res ;
   }
private:
   int m_init;
};

double Calc()
  {
   double Res = TComputer(1 e8).Compute();
   Print("Calculated");
   Sleep(5000);
   EventChartCustom(0, 0, 0, 0, "");
   return(Res);
  }
//+------------------------------------------------------------------+

void OnChartEvent(const int id, const long&, const double&, const string&)
  {
   static bool aaa = true;
   if(id == CHARTEVENT_KEYDOWN && aaa)
     {
      Print("Calculating...");
      double res = Calc();
      Print(res);
      aaa = false;
     }
   if(id == CHARTEVENT_CUSTOM)
      aaa = true;
  }

TComputer is a fancy, third-party library, which the whole world will use))))) No, not even so, it will be a part of the local standard library)))))

Naturally, your code, which has been working smoothly for a long time, will be translated to it, and even without tests, and why, everything is so trivial and exactly such a call is shown in the help))))

I'm talking about the fact that unfinished solutions, thrown in once, lead to exactly such consequences. Believe me, I've been through it. Asynchronous programming is exactly about such tricks.

[Vladimir Simakov]

fxsaber #:

This kind of thing would be added for credibility.

Well done! That's right. Now we don't need a constructor)

But immediately a problem came up. EventChartCustom ended with false. What do we do next, how will we protect ourselves from our evil-evil?))))))

[fxsaber]

Vladimir Simakov #:

EventChartCustom ended with false. What do we do next, how do we protect ourselves from our evil-evil?))))))

Exactly what the code says.

[Vladimir Simakov]

Speaking of birds, there is a solution if you think about the future right away, but you have to do it at the terminal level.

As an example, so, the first thing that came to mind.

We need to add two fields to all event calls (OnX).

ulong id; // monotonically increases at each event.

ulong lastFinishedId; // id of the last OnX, which was completed at the moment when this event started forming.

[Vladimir Simakov]

fxsaber #:

Exactly what the code says.

So, if the button is pressed again, we get an unexpected call?

[fxsaber]

Vladimir Simakov #:

So if a button was pressed repeatedly, we get an unexpected call?

Yes. When ChartEventCustom returns false, it is an abnormal situation. Adding Solution1 can help with it.

[fxsaber]

Vladimir Simakov #:

Because that's what the result will be:

Stubbornly duplicating EventChartCustom calls. It's just a matter of enthusiasm to complete the foolproofing.

class EventLocker{
public:
   EventLocker( const ushort EventID = 0 ){
      EventLocker::m_lock = true;
      EventLocker::m_EventID = EventID;      
   }
   ~EventLocker(){
      EventLocker::m_lock = ::EventChartCustom(-1, EventLocker::m_EventID, 0, 0, NULL);
   }
   static void Unlock( const int &id ){EventLocker::m_lock = EventLocker::m_lock &&
                                                             (id != CHARTEVENT_CUSTOM + EventLocker::m_EventID);}
   static bool Locked() {return EventLocker::m_lock;}
private:
   static bool m_lock;
   static ushort m_EventID;
};

static bool EventLocker::m_lock = false;
static ushort EventLocker::m_EventID = 0;

double Calc()
  {
   double Res = 0;

   for(int i = 0; i < 1 e8; i++)
      Res += MathSin(MathRand());
   return(Res);
  }
//+------------------------------------------------------------------+

void OnChartEvent(const int id, const long&, const double&, const string&)
  {
   if(id == CHARTEVENT_KEYDOWN && !EventLocker::Locked())
     {
      EventLocker lk(123);
      Print("Calculating...");
      Print(Calc());
     }
 
   EventLocker::Unlock(id);
  }

As a small step.

[Vladimir Simakov]

fxsaber #:

You persistently duplicate calls of EventChartCustom. It's just a matter of enthusiasm to complete the foolproofing.

As a small step.

Except there are two ways to do it. Either you know about these problems and handle them, or you take a beating in the release.