RefreshRates, init() and start()

 

Hi,

I have EA like this:

int
init() {
  long_running_function_that_access_timeseries_array();
}

int
start() {
  while(!IsStopped()) {
    RefreshRates();
    another_function_that_access_timeseries_array();
    Sleep(50);
  }
}

Suppose that init() takes 30 minutes to complete.

After that MT4 will call my start() function on incoming tick. Did MT4 already refreshed missing data in timeseries array before calling start() for a first time? Or I have "hole" in timeseries array that will be filled when RefreshRates is called for a first time?

Thanks, Luke

 
That's a great question, one that I would like to know the answer to as well. I have experienced a similar issue when switching from H1 to M1, at the first tick on M1 not all the M1 data is there . . .
 

No, your EA won't even start. AFAIK there is a maximum allowed time for init(), deinit(), and for library calls. Once the time is over the EA gets 'closed' (it is still on the chart, but doesn't process anything anymore) for Timeout reason.

I am not sure about the library calls, but one of my testing EA's got a timeout when stuck in a Orderclose loop for 90open orders and a lot of requotes.

@Raptor, i am not sure with your issue, but a code like:

if(TimeCurrent()>Time[1]) might solve the problem

 
zzuegg:

@Raptor, i am not sure with your issue, but a code like:

if(TimeCurrent()>Time[1]) might solve the problem

Yep, good point, it's an old(ish) EA that behave like an Indicator . . . I'll have to revisit it and see if I can fix it ;-)
 

Luke_ca:

Suppose that init() takes 30 minutes to complete.

After that MT4 will call my start() function on incoming tick. Did MT4 already refreshed missing data in timeseries array before calling start() for a first time? Or I have "hole" in timeseries array that will be filled when RefreshRates is called for a first time?

  1. On the call to start, everything should be refreshed, so RefreshRates is needed ONLY if you do multiple server calls, take a long time to calculate, or use a sleep loop instead of return/wait for tick.
  2. On the call to init, charts may not be set up correctly yet. Definitely history not loaded. You shouldn't be doing anything in init. Set a flag and do it on the first call to start.
  3. Init must return within TWO SECONDS
 
zzuegg:

No, your EA won't even start. AFAIK there is a maximum allowed time for init(), deinit(), and for library calls. Once the time is over the EA gets 'closed' (it is still on the chart, but doesn't process anything anymore) for Timeout reason.

@Raptor, i am not sure with your issue, but a code like:

if(TimeCurrent()>Time[1]) might solve the problem


Ok, right that what is happening. My start() function is called only once if init takes too long.

I plan to change my code this way:

int start() {
  long_running_function_that_access_timeseries_array();
  another_function_that_access_timeseries_array();
}

Will second function have current data in timeseries arrays or do I need to call RefreshRates()?

Many thanks for your replies.

Luke

 

if you need the long_running only once you can also use a flag:

int start(){
  static bool isInit=false;
  if(!isInit) {
    long_running();
    isInit=true;
  }
  another_function();
}
 
WHRoeder:
  1. Init must return within TWO SECONDS


Many thanks for this link. This should solve my "weekend problem" :-)

Regards, Luke

 
zzuegg:

@Raptor, i am not sure with your issue, but a code like:

if(TimeCurrent()>Time[1]) might solve the problem

Just seen an unexpected issue with one of my Functions while testing it on Demo, something like what you have suggested might help but TimeCurrent() will be greater than Time[1] while Time[0] is forming . . .

So how about this ?

if (TimeCurrent() - TimeCurrent()%60 > iTime(NULL, PERIOD_M1, 0) )  Print("M1 data out of date . .  ! ! ");
 
TimeCurrent, Time[1] and iTime will not change until you call refreshRates
 
WHRoeder:
TimeCurrent, Time[1] and iTime will not change until you call refreshRates
But they will change when a new tick arrives and start() is called, no ?
Reason: