FORTS Please help - page 9

 
komposter:

What is the difference between "not" and "not ready" for the programme (and the programmer)?

If the data is not ready, there will be an error.

Or maybe this information is not instantly available either, which is why it is not shown.

And in order to avoid "getting into" the server.

Also, you are our "reader"... Question:

Why do they build the timeseries if the data are ready ( CopyTime(symbol,period,first_date+PeriodSeconds(period),1,times) )?

Если мы успешно прошли все проверки, то сделаем последнюю попытку обойтись без обращения к торговому серверу. Сначала узнаем начальную дату, для которой доступны минутные данные в формате HCC.
Запросим это значение функцией SeriesInfoInteger() с модификатором SERIES_TERMINAL_FIRSTDATE и опять сравним со значением параметра start_date.

   if(SeriesInfoInteger(symbol,PERIOD_M1,SERIES_TERMINAL_FIRSTDATE,first_date))
     {
      //--- there is loaded data to build timeseries
      if(first_date>0)
        {
         //--- force timeseries build                                            
         CopyTime(symbol,period,first_date+PeriodSeconds(period),1,times);
         //--- check date
         if(SeriesInfoInteger(symbol,period,SERIES_FIRSTDATE,first_date))
            if(first_date>0 && first_date<=start_date) return(2);
        }
     }
 
 
MigVRN:
That's right - it loads and prepares what is there. But due to the fact that any delay in the indicator slows down the chat with everything that hangs on it - we made it so in indicators if the series is not ready at the time of the call - the function will return an error and INITIALIZE the data preparation. After a while it will no longer return an error. This is what is happening in your logs.

MigVRN!

Chukcha has reread the help and has to NOT agree with you.

"That's right - it bothloads and prepares what's there."

This is your speculation....

But the reference says that function SeriesInfoInteger with identifierSERIES_TERMINAL_FIRSTDATE

Should return:

SERIES_TERMINAL_FIRSTDATE

The very first date in the history by symbol in the client terminal regardless of period

It must not prepare anything!

There is data in the terminal history - get the date.

No - it returns "0".

 
A new day and round and round again.
 
barabashkakvn:
A new day and round and round again.
Show in the reference, something OTHER
 
papaklass:
Prepare the data and work with it. You can say 150 times that something is wrong, and get 150 answers about what to do. It's your job, so take care of yourself!

Thank you, but you know very well that EVERYTHING has to be proven.

SD thinks that returning 0, when the data is present, is not an error of their function.

If so, it MUST be written in the documentation!

 

Mikalas:

Should, shouldn't - that's all we talk about. Well, you can see for yourself how it works :)

The only thing I can agree with is that it is not quite clear which data is ready AT ONCE (available at any moment) and which data the terminal prepares when you access it.

I(!) understand that when accessing any timeseries data (time and price, number of bars,ENUM_SERIES_INFO_INTEGER enumeration, or maybe I forgot something else), the data is not ready at once.

To avoid such situations, it's written in the help:

Because mql5-program can access data by any symbol and timeframe, there is a possibility that the data of a required timeframe have not yet been generated in the terminal, or the required price data are not synchronized with the trade server. In this case, the waiting time of data readiness is difficult to predict.

Algorithms using cycles of waiting for data readiness are not the best solution. The only exception in this case - scripts, because they have no other choice of algorithm, due to the lack of event processing. For custom indicators such algorithms, as well as any other waiting loops, are strongly not recommended, as they lead to the stopping of the calculation of all indicators and other price data processing for this symbol.

For Expert Advisors and custom indicators it is better to usethe event-based processingmodel. If the processing of events OnTick() or OnCalculate() hasn't managed to get all the necessary data of the required time series, you should leave the event handler, expecting to have access to the data during the next call of the handler.

 
MigVRN:

Should, shouldn't - that's all we talk about. Well, you can see for yourself how it works :)

The only thing I can agree with is that it is not quite clear which data is ready AT ONCE (available at any moment) and which data the terminal prepares when you access it.

I(!) understand that when accessing any timeseries data (time and price, number of bars,ENUM_SERIES_INFO_INTEGER enumeration, or maybe I forgot something else), the data is not ready at once.

To avoid such situations, it's written in the help:

Because mql5-program can access data by any symbol and timeframe, there is a possibility that the data of a required timeframe have not yet been generated in the terminal, or the required price data are not synchronized with the trade server. In this case, the waiting time of data readiness is difficult to predict.

Algorithms using cycles of waiting for data readiness are not the best solution. The only exception in this case - scripts, because they have no other choice of algorithm, due to the lack of event processing. For custom indicators such algorithms, as well as any other waiting loops, are strongly not recommended, as they lead to the stopping of the calculation of all indicators and other price data processing for this symbol.

For Expert Advisors and custom indicators it is better to usethe event-based processingmodel. If during the processing of events OnTick() or OnCalculate() you did not get all of the necessary data of the required timeseries, you should exit the event handler, expecting to have access to the data during the next call of the handler.

Andrew!

I don't know about you, but I have been working with documentation for many years.

Look, from the documentation it follows, as I(!) understood.

1. Let's check if there is history data for the symbol in the terminal (SeriesInfoInteger with the identifierSERIES_TERMINAL_FIRSTDATE)

Maybe, I'm not arguing about it, it both builds and initializes something.

2. No data (returns an empty start date of history) - goes to server for data.

If there is a date, we construct the specified timeframe using theCopyTime(symbol,period,first_date+PeriodSeconds(period),1,times) function;

4. We check the beginning of the timeseries with the given date(SeriesInfoInteger(symbol,period,SERIES_FIRSTDATE,first_date).

It's written in documentation.

But when I(!) ask for history data by symbol(not by time series!!!!) in the terminal, which are EXACTLY there

function returns "0".

Do you think this is RIGHT?

 
Mikalas:

BUT, when I(!) ask for history data by symbol(not by time-series!!!!) in the terminal, which is EXACTLY there

the function returns "0".

Do you think this is RIGHT?

The data (not prepared) is on disk. The data (prepared) may be on the adjacent chat. But there is no prepared data on the chat which is running the indirection. Therefore there is an error. It is correct. But it is not convenient :)

Although I don't like such questions myself - is it critical for you to request the data from the indicator for the adjacent characters? (taking into account what is written in the help and my example - how an indicator can slow down the execution of Expert Advisor and chat). You can bypass all of these difficulties...

 
papaklass:

You are asking for "FIRSDDATE", not data. The date is probably there, but the data may be missing due to economy. Why pump up data for all characters if they are not being used at the moment. The developers have taken the rational path of pumping up the data only when the user accesses that data. This is the normal approach. You, working with the terminal, should KNOW this and act accordingly.

Instead of wasting your time on trading you are stuck on elementary stuff and you are wasting your time. Spare your time. :)

The robots are trading for me, I'm not at home at the moment...

And I need indicator just to improve my trading :)

 
Mikalas:

Andrei!

I don't know about you, but I have been working with documentation for many years.

Look, from the documentation it follows, as I(!) understand.

1. Let's see if there is history data on the symbol in the terminal (SeriesInfoInteger with identifierSERIES_TERMINAL_FIRSTDATE)

Maybe, I'm not arguing about it, it both builds and initializes something.

2. No data (returns an empty start date of history) - goes to server for data.

If there is a date, we construct the specified timeframe using theCopyTime(symbol,period,first_date+PeriodSeconds(period),1,times) function;

4. We check the beginning of the timeseries with the given date(SeriesInfoInteger(symbol,period,SERIES_FIRSTDATE,first_date).

It's written in documentation.

But when I(!) ask for history data by symbol(not by time series!!!!) in the terminal, which are EXACTLY there

function returns "0".

Do you think this is RIGHT?

Read the documentation more carefully, not selectively. The presence of history data on the disk does not mean "it's definitely there" for the terminal. In this case (when accessed from the indicator), the functions only work with the timeseries cache in memory. It means that synchronous memory access is performed and if there is no prepared timeseries there, the date SERIES_FIRSTDATE (of the first element of the array) will not be returned. But of course, the request initiates preparation-loading of timeseries into memory.

SERIES_TERMINAL_FIRSTDATE request is connected with database initialization and synchronization with server, so the first call won't work immediately anyway.

In principle, the ability to get the required history is checked using SERIES_SERVER_FIRSTDATE . I.e. you can of course count on X iterations of history request, but if the terminal confirms the presence of history via SERIES_SERVER_FIRSTDATE, then the availability of relevant timeseries data is only a matter of time (synchronization of m1 database with the server and generation of timeseries).

Reason: