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

New comment
 
Slava:

It is possible to try to determine.

If it's minutes, you can compare the time of the last bar with TimeCurrent(). If it is not M1, you can ask iTime(_Symbol,PERIOD_M1,0) and compare with TimeCurrent().

You can compare the Bid or Last price (depending on the symbol) with the Close price of the last bar. You can directly ask SymbolInfoTick for the current symbol. In addition to the Bid and Last, there is also the tick time

Thank you, at least some information about where and how to look for bugs if something went wrong

but I think, that all the same need embedded function to check the status, or better yet it would be a flag, like int _LastError, which would store the number of missed ticks, it would be convenient when calling OnCalculate() - in complex calculations do immediately return, to release the symbol stream

 
Igor Makanu:

Thanks, at least some information about where and how to look for bugs if something went wrong

but I think, that all the same need embedded function to check the status, or better yet, it would be a flag, like int _LastError, which would store the number of missed ticks, it would be convenient when calling OnCalculate() - in complex calculations do immediately return, to release the symbol stream

thought, pondered.... this is not the solution. what will the knowledge of missed ticks be (Slava says, that it is guaranteed that the indicator receives ALL ticks, and this fact leads to all hangs of not only MQL-programs, but even the client terminal)? in any case, these ticks will have to be collected and processed, and that means, if we missed a tick, why suddenly hope that the next time it will be possible? - it's a vicious circle.

I was thinking... maybe the developers should introduce something similar to the exceptions? The coming of a new tick should interrupt all operations, calculations in the indicator at that moment, and any standard MQL function should return an error during its execution, if a new tick comes at that time ... Then the work with the indicator becomes clear, convenient and predictable. For the other types of programs (scripts, Expert Advisors) it's almost unnecessary.

And all sorts of checks of ticks in the indicator for their relevance - to put it mildly, this is not the solution.

 

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

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

 
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 ticks pack reception, instead of on each tick.

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

So, you will be able to have a very fast indicator with such a design?

//+-------------------------------------------+
int OnInit() 
  {
  EventSetMillisecondTimer(200);
//-
  return(INIT_SUCCEEDED);
 }

//+-------------------------------------------+
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[])
 {
  // Здесь ничего не делаем, нам не нужен в данном случае OnCalculate
  return(rates_total);
 }

//+-------------------------------------------+
void OnTimer()
 {
  // Здесь расчёты, и вывод информации на график в виде графических объектов
 }

If so, this is great news!

 
Renat Fatkhullin:

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

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

And if you make a standard function for getting a synchronized multicurrency array, it will be a real holiday.

 
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 ticks pack reception, instead of on each tick.

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

Good idea!

And preferably it should work without any#property by default.

If someone needs it otherwise, then let them put#property.

 
The solution for receiving ticks in packs is good and probably not very expensive, if we do not need real time (but it is unclear how EAs will work with indicators which work at "yesterday's" prices, but never mind).

But there is another class of problems - realtime, on every tick. In this case you either have time to make calculations after the tick or not, and then the trading solution will be irrelevant (there is no third way). That's why there is only one correct way to solve the problem - interrupt all current calculations and return the error when a new tick comes. Otherwise one can forget about real-time. Now ticks are getting faster and faster every day, and it's a long way to go, so it's necessary to plan for the future, not to mention the fact that it's impossible to process all ticks without lags in time in the present.

 
_o0O:
The solution for receiving ticks in packs is good and probably not very expensive, if we do not need real time (but it is unclear how EAs will work with indicators which work at "yesterday's" prices, but never mind).

But there is another class of tasks - realtime, on every tick. You either have time to perform estimations after the receipt of a tick or you don't, and the trade solution will be irrelevant (there is no third alternative). That's why there is only one correct way to solve the problem - interrupt all current calculations and return the error when a new tick comes. Otherwise we can forget about real-time. Now ticks are getting faster and faster every day, and it's a long way to go, so it's necessary to plan for the future, not to mention the fact that it's impossible to process all ticks without lags in time in the present.

The most part of indicators EAs work with closed bar[1], that's why skipping of ticks does not matter, it is actual for indicators working with ticks, but there are not many of them, for them it is possible to allocate"#property tester_everytick_calculate".

And again, if you need super-ticks, you don't need an indicator for that, all this can be written in the Expert Advisor's code. So, it is not reasonable to slow down the indicator's work for the sake of every tick.

We wait for"#property tester_everytick_calculate".

 
Vitaly Muzichenko:

The most part of indicators EAs work with closed bar[1], that's why skipping of ticks does not matter, it is actual for indicators working with ticks, but there are not many of them, they just can be allocated"#property tester_everytick_calculate".

And again, if you need super-ticks, you don't need an indicator for that, all this can be written in the Expert Advisor's code. So, it is not reasonable to slow down the indicator's work for the sake of every tick.

Waiting for"#property tester_everytick_calculate"


OK, and how does what you said disagree with what I said?
 
It may be useful to someone. I have a multi-currency indicator, so the main capacitive calculations I do in the initialization block and only the rendering into the oncalculus. But this is the solution for situations when the indicator lines themselves do not contain complex calculations. In my case it is a portfolio indicator displaying the graph of portfolio behaviour.
12345678910
New comment
Reason: