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

New comment
 
fxsaber #:

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

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

bool EventLocker::m_lock = false;
bool EventLocker::m_hasSended = true;

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;
      Print("Calculating...");
      Print(Calc());
     }
   if(id == CHARTEVENT_CUSTOM)
      EventLocker::Unlock();
}

Do you think it will help?

 
fxsaber #:

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

As a small step.

Another point. You affect the static state of the object by the parameter of non-static member functions, I'm talking about the constructor now. It's not a very sensible solution. I would say that it is categorically harmful.

 
Vladimir Simakov #:

Do you think it'll help?

No, of course not. Duplicating EventChartCustom again.

 
Vladimir Simakov #:

One more thing. You influence the static state of the object by the parameter of non-static member functions, I'm talking about the constructor now. This is not a very reasonable solution. I would say that it is categorically harmful.

This is not a biblioteka in a design bureau, but a handicraft that can and should be improved and discussed. That is what we are doing.

Try creating a similar library at QB that takes into account many scenarios and is user friendly.

I have no enthusiasm for this topic, unfortunately.

 
fxsaber #:

No, of course. Duplication of EventChartCustom again.

That's not the post I was writing to.

I was writing to this one

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

 
Vladimir Simakov #:

Wrong post I was writing to.

This one

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

Once again, there should be no duplication of this function. It should be called only in the destructor and once on exit from all calculations.

Decision1 is a good help in case of abnormal operation of Decision2.

 

Has anyone managed to run any optimisation using Alglib?

I would be grateful if someone could share links to examples of use.

 
fxsaber #:

Once again, there should be no duplication of this function. It should be called only in the destructor and once on exit from all calculations.

Decision1 is a good help in case of abnormal operation of Decision2.

If I see this right, is this about multi thread safety?

If that is the case, none of the proposed solution is safe.

For thread safety, an atomic operation is mandatory, only one function in MQL allows such, and it has not been used here.

Actually, to make OnEvent be multi thread safe, a critical section is required. Such can be built with

GlobalVariableSetOnCondition.

Or am I on wrong track here?
 
Vladimir Simakov #:

The button will be pressed a second time while the instructions after the call are being executed

but before the exit from the current OnChartEvent call (the same Print won't even start executing yet), and, by the law of meanness, that's when all conditions for the most unfavourable scenario)))) will be created. Bingo!!! It will be an epic and instructive fiasco))))))

Question: who will be to blame?

Answer: the one who uses asynchronousness in the combat code, poorly realising the depth of possible depths and the pain that lives there.

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

Somehow this is how it should be:

Thank you for pointing out such a negative scenario. Yes, the solution proposed was crude, ill-conceived, but it was not even a solution, but a direction in which to go.

My question is a bit different. Since I am not at all good at OOP, your code is clear to me, but not quite.

Can you tell me, is this code without OOP equal to the one below with OOP? And if not, what is the difference?

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&)
  {
   static bool Unlock = true;
   if(id == CHARTEVENT_KEYDOWN && Unlock)
     {
      Unlock = false;
      Print("Calculating...");
      Print(Calc());
      if(!EventChartCustom(0, 0, 0, 0, ""))
         Unlock = true;
     }
   if(id == CHARTEVENT_CUSTOM)
      Unlock = true;
  }
class EventLocker{
public:
   EventLocker(){
      m_lock = true;
   }
   ~EventLocker(){
      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;
//+------------------------------------------------------------------+
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;
      Print("Calculating...");
      Print(Calc());
     }
   if(id == CHARTEVENT_CUSTOM)
      EventLocker::Unlock();
  }
 
Dominik Egert #:
If I understand correctly, we are talking about multi-threaded security?

If I understand correctly, we are talking about different tasks.

Fxsaber had a task to eliminate the probability of repeated execution of a long calculation, which could cause human error.

I usually solved this problem by assigning two keys instead of one as a trigger for calculations.

My task was to thin the queue of events initiated by EventChartCustom, and if somewhere there is a failure and the queue once another time will not be cleared nothing terrible will happen. (not solved yet, but there is a direction).

On the task and the solution.

1...262263264265266267268269270271
New comment