ChartIndicatorGet function has problem

 

OnDeinit() event will not called if you call ChartIndicatorGet(0,ChartWindowOnDropped(),MQLInfoString(MQL_PROGRAM_NAME)) like this. (It's only on indicator process)

In this code you will don't see print "reason: "+reason in log when you remove indicator or any deinit actions until you recompile it.

#property indicator_chart_window

int OnInit()
{
Print("ChartIndicatorGet: "+ChartIndicatorGet(0,ChartWindowOnDropped(),MQLInfoString(MQL_PROGRAM_NAME)));
return(INIT_SUCCEEDED);
}

void OnDeinit(const int reason)
{
Print("reason: "+reason);
}

int OnCalculate(const int rates_total,
                const int prev_calculated,
                const datetime &time[],
                const double &open[],
                const double &high[],
                const double &low[],
                const double &close[],
                const long &tick_volume[],
                const long &volume[],
                const int &spread[])
{
return(rates_total);
}
 
momocoong:
ChartIndicatorGet

This is not a bug, but expected behaviour. The function ChartIndicatorGet increases internal count of the indicator locks.

Getting a handle from a function ChartIndicatorGet increases the internal counter for using this indicator. The terminal execution system keeps loaded all indicators whose counter is greater than zero. Therefore, an indicator that is no longer needed must be explicitly freed by calling IndicatorRelease. Otherwise, the indicator will remain idle and consume resources.

MQL5 Book: Creating application programs / Working with charts / Managing indicators on the chart
MQL5 Book: Creating application programs / Working with charts / Managing indicators on the chart
  • www.mql5.com
As we have already found out, charts are the execution and visualization environment for indicators. Their close connection finds additional...
 

So I created my own function instead. It's work! I create this function for check the indicator is called by EA or not.

bool iCustomState()
{
#ifdef __MQL4__
   if(ChartWindowOnDropped()==-1)
   return true;

return false;
#else
int window_dropped=ChartWindowOnDropped();

   for(int i=ChartIndicatorsTotal(0,window_dropped)-1;i>=0;i--)
   {
      if(ChartIndicatorName(0,window_dropped,i)==MQLInfoString(MQL_PROGRAM_NAME))
      return false;
   }

return true;
#endif
}
 
momocoong #:

So I created my own function instead. It's work! I create this function for check the indicator is called by EA or not.

I'm not sure how this code can check if indicator is called by EA or not.

Also you can have multiple copies of the same indicator (with different parameters) on the same chart, so they will have the same name, and your code does not necessarily return status of current instance, but first visited.

 

This is the only way to check iCustom called status. My indicator have online authentication. But I want it check only run with user.

MQL5&5 have not "iCustom called status checker" function. So I have to use this method.

 
momocoong #:

This is the only way to check iCustom called status. My indicator have online authentication. But I want it check only run with user.

MQL5&5 have not "iCustom called status checker" function. So I have to use this method.

You're right that MQL5 does not provide a method to detect how an indicator is created: manually or programmatically via iCustom/IndicatorCreate (I created a ticket with corresponding feature request in the sevice desk back in 2014, when the service desk existed) - they declined my proposal.

Yet I don't see how your code can solve the task. You check if indicator is presented on the chart. It can be added there manually or programmatically.

On the other hand, it's not clear why you need to distinguish the status in your use case: if your indicator require online authentication, you can simply stop it without authentication, no matter how it's created. 

 
momocoong #:

So I created my own function instead. It's work! I create this function for check the indicator is called by EA or not.

It's unreliable. At best it will work for your specific use case. However it's not generic and depends of how it's used, so you can be sure it will fail sooner or later (Murphy's law).