MQL5 bug when working with iClose/iOpen timeseries access, etc. - page 9

[Unicornis]

Vitaly Muzichenko:

So, it will be possible to have very fast indicator with such construction?

More likely not, OnCalculate will not be called on every tick, but after a pack of ticks.

If so, this is great news!

[fxsaber]

Renat Fatkhullin:

We have an idea for indicators, which do not contain the #property tester_everytick_calculate flag, to include the calculation mode based on the receipt of a pack of ticks, instead of on each tick.

This will radically solve the problem of tardy indicators, preserving the possibility of guaranteed processing of each tick for some indicators.

I propose another solution.

SymbolInfoTick

Returns the current prices of a specified symbol in a variable of MqlTick type.

bool  SymbolInfoTick( 
   string    symbol,     // символ 
   MqlTick&  tick        // ссылка на структуру
   bool      IndicatorMode = true; // индикаторный или реальный (текущий) тик
   );

Parameters

symbol

[Symbol name.

tick .

[out] A structure reference ofMqlTick type, the current prices and last price update time are placed in it.

IndicatorMode

[out] true - in indicators returns tick that triggered the current NewCalculate, false - current (real time) tick of a symbol.

Returned value

Returns true if successful, otherwise false.

Then in OnCalculate it will be enough to write only this construct

// Возвращает true, если текущий и индикаторный тики совпадают
bool IsRealTick( void )
{
  MqlTick Tick1, Tick2;
  
  return(SymbolInfoTick(_Symbol, Tick1) && SymbolInfoTick(_Symbol, Tick2, false) && (Tick1.time_msc == Time2.time_msc));
}

int OnCalculate( ... )
{
  if (prev_calculated && !IsRealTick())
    return(prev_calculated); // Если тик устарел, идем к следующему
    
  // Body
  
  return(rates_total);
}

This solution would be more flexible and convenient to use and implement.

SZY It would be better to have numbering of ticks, with possibility to get the number of current and indicator tick. But this variant is more difficult for developers. Therefore, probably, it is not necessary.

[fxsaber]

fxsaber:

I suggest another solution.

If nothing is done by the developers (which is a very good option, by the way), it is still possible to bypass all the brakes in this way

int OnCalculate( ... )
{
  static ulong MinTimeMsc = 0
  const ulong StartTime = GetMicrosecondCount();
  
  MqlTick Tick;
  const bool Res = prev_calculated && SymbolInfoTick(_Symbol, Tick);
  
  if (Res && (Tick.timeMsc < MinTimeMsc))
    return(prev_calculated); // Если тик устарел, идем к следующему
    
  // Body
  
  if (Res)
    MinTimeMsc = Tick.time_msc + (GetMicrosecondCount - StartTime) / 2000;
  
  return(rates_total);
}

[Unicornis]

fxsaber:

If the developers do nothing (which is a very good option, by the way), it is possible to bypass all the brakes now in this way

Well, we don't need ticks in the middle of a bar, they are forcedly skipped anyway. Let's wait for implementation by mql.

[fxsaber]

Unicornis:

Well, we don't need ticks in the middle of a bar, they are forcedly skipped anyway. Let's wait for mql's implementation.

Honestly, I don't understand, what prevented sufferers from writing a solution to their problem themselves?

And why developers should change something here?

The solution can be implemented as an mqh-file and connected to any indicator, as it is implemented in Init_Sync. But it requires a lot of code that is not very obvious. And here it is just few lines.

[Farkhat Guzairov]

Renat Fatkhullin:

Frozen update of someone else's invisible timeframe after reconnect communication was sorted out and fixed. The reason was incorrect cache statuses after the reconnect.

Beta version 1946 available via Help -> Check Desktop Updates -> Latest Beta Version.

Rinat, 3 days of tests no problems, thanks!

[Unicornis]

fxsaber:

Honestly, I don't understand what prevented sufferers from writing a solution to their problem themselves?

And why should the developers change something here?

Sufferers cannot change the number of incoming ticks in the indicator in any way, they skip them in the indicator until a new bar, if the indicator counts for a long time, the ticks are skipped anyway. Somehow we have to adjust to the reality.

If for one symbol the peak value is ~800 ticks per minute, then for synthetic of several symbols already 2300 ticks per minute. Opening one synthetic and one symbol from it peaks at ~3000 ticks per minute. Add another timeframe of the same synthetic and the same symbol, and we get... Ok, Elder's screens were three, we get ~9000 ticks per minute or 150 ticks per second. Rinat has already written about performance issues. Why pass an idle 150 ticks per second through a multisymbol-mtf indicator when you need 1-n tick per minute for all tf symbols? Likewise, the benefits of hosting mql include no overhead from the host system, the terminal is the same host only for indicators and EAs. If the indicator calculation consists of RSI(3) + EMA(5) + EMA(7), then of course no problem in the next 10 years.

In the synthetic (actually it is a multisymbol indicator from the terminal) the developers somehow came up with the idea to paste some symbols, why should we duplicate the elements of this system (let's assume it is not even perfect) at the level of programmer's craftsmanship in the indicator? If the system can be simplified, why not do it? When the Earth was still standing on three elephants, the 5-second timef was not invented for nothing.

Upd. You can introduce the timeframe 5 seconds without history and the ticks will be only once in 5 seconds, and to test all sorts of solutions (compilation of the indicator with some prefix for working only on 5S, other indicators will not run on it) - the existing ideology of the terminal will not change, so we can change and modify solutions, and the best/optimal solution will be formed during the testing.

(LMS to your development libraries, synthetics, detached windows, etc. Developers).

[fxsaber]

Unicornis:

Even if there are a million ticks per minute, this does not make the solution unworkable.

[Unicornis]

fxsaber:

A million ticks per minute doesn't make the solution unworkable.

The question is not about the workability of the solution. The reasonability of calling the indicator at every reached tick before which an unknown number of ticks was missed, besides, some obsolescence of a tick is considered? If something is skipped (with increasing load) and the relevance of the tick is not known, then this situation doesn't solve the analytical problem - if not, why bother with it. In general, prohibit the flow of ticks into indicators, leave the ticks to the indicator from the platform once every 5 seconds - 12 ticks per minute, it's enough.

[fxsaber]

Unicornis:

The question is not about the workability of the solution. The reasonability of calling the indicator at each reached tick before which an unknown number of ticks was missed, besides some obsolescence of a tick is considered ??? If something is skipped (with increasing load) and the relevance of the tick is not known, then this situation doesn't solve the analytical problem - if not, then why bother with it. In general, the flow of ticks into indicators should be forbidden, the ticks coming from the platform every 5 seconds should be left - 12 ticks per minute, it's enough.

Stupidity.