FORTS Please help - page 8

New comment
 
MigVRN:

It always has been.

He's a ticking expert not working. And everything else on the chat. Timer and custom events really didn't check.

Also from help

...The service files in HCC format act as a source of data to build the price data for requested timeframes in HC format. The data in the HC format are timeseries, which are maximally prepared for quick access. They are created only at requests of a chart or mql5-program in the volume not exceeding the "Max bars in charts" parameter, and are saved for further use in files with the hc extension.

To save resources, the data on the timeframe are loaded and stored in the RAM only when required. In case of long absence of requests the data are unloaded from the RAM saving them into a file. Data for each timeframe are prepared independently from the ready data for other timeframes. The rules for data preparation and availability are the same for all timeframes. So, despite the fact that the unit of data storage in the HCC format is the minute bar, the availability of the data in the HCC format does not mean the availability and accessibility of the M1 timeframe data in the same volume in the HC format.

:)

So who will load them into memory, if notSeriesInfoInteger(symbol,PERIOD_M1,SERIES_TERMINAL_FIRSTDATE,first_date)

There is no other function!!!!

Why go to the server when the data IS in the terminal????

 
Mikalas:

:)

So who will load them into memory, if notSeriesInfoInteger(symbol,PERIOD_M1,SERIES_TERMINAL_FIRSTDATE,first_date)

There is no other function!!!!

Why go to the server when the data IS in the terminal????

That's right - it loads what is there. But due to the fact that any delay in indicator slows down the chat with all what's hanging on it - in indicators we made so that if series is not ready at the moment of call - function will return the error and INITIALIZE data preparation. After a while it will no longer return an error. This is what is happening in your logs.
 
MigVRN:
Because it is the FIRST time it addresses this particular series.

I did the cycle:

long first_date = 0;
    datetime times[1];
    int fail_cnt = 0;
//---
    while ( fail_cnt < 1000 )
    {
      ResetLastError();  
      if ( SeriesInfoInteger( symbol, PERIOD_M1, SERIES_TERMINAL_FIRSTDATE, first_date ) )
      {
        if ( first_date > 0 )
        {
//--- force timeseries build
          CopyTime( symbol, period, datetime( first_date ) + PeriodSeconds( period ), 1, times );
//--- check date
          if ( SeriesInfoInteger( symbol, period, SERIES_FIRSTDATE, first_date ) )
//---        
          if ( first_date > 0 && first_date <= long( start_date ) )
          {
            return( Bars( symbol, period, start_date, end_date ) );
          } 
        }
      }
      fail_cnt++;
    }

Guess what the result is?

 
MigVRN:
All right - it loads and prepares what is there. But due to the fact that any delay in indicator slows down the chat with everything hanging on it - in indicators we made it so that if series is not ready at the moment of call - function will return error and INITIALIZE data preparation. After a while it will no longer return an error. This is what you have in your logs.
This time may take either several OnCalculate() calls or even a few seconds. This is how the money-making machine works. This is why it is incorrect to call anything related to getting data from the indicator OnInit().
 
Mikalas:

I did the cycle:

Guess what the result is?

barabashkakvn:
This time may take either several OnCalculate() calls or even several seconds. This is how a money making machine works. That's why it's wrong to call anything related to getting data from OnInit() of the indicator.

That's right - the cycle is VERY fast. no time to prepare... I understand that from a developer's (us) point of view it's HELL :) But you will have to get used to it.

By the way, Sleep() does not work in indicators

:)

 
MigVRN:

That's right - the cycle is VERY fast. no time to prepare... I understand that from a developer's (us) point of view it's HELL :) But you'll have to get used to it...

By the way, Sleep() does not work in indicators

:)

Thank you, Andrey!

The question is not for you, it's rhetorical:

Why do I need

SeriesInfoInteger( symbol, PERIOD_M1, SERIES_TERMINAL_FIRSTDATE, first_date ) ????

If I don't get an answer, I have to contact the server (there really may not be any data in the terminal) !

Thank you all. The chukchi got it....

... And "respect" to MQ !

P/S I won't read the help again...

 
Mikalas:

komposter!

When you don't understand or misunderstand something, no one calls you a Chukchi.

Why should they?

When I don't understand, I try to hear what I am told.

And you have stubbornly ignored the experience of many people who have faced a similar problem and solved it.

That's what I call a "chukcha writer".

 
Mikalas:

Then what is the

SeriesInfoInteger( symbol, PERIOD_M1, SERIES_TERMINAL_FIRSTDATE, first_date ) ????

If I don't get an answer, I have to go to server (the data in the terminal may really not be there) !

To get the data if it's ready or to initiate a preparation if the request happens for the first time.
 
MigVRN:

That's right - the cycle is VERY fast. no time to prepare... I understand that from a developer's (us) point of view it's HELL :) But you'll have to get used to it...

By the way, Sleep() does not work in indicators

:)

By the way, what prevents the developers from using theSERIES_TERMINAL_FIRSTDATE

return:

-1 - no data

0 - no data available but not ready

> 0 - date itself

 
Mikalas:

By the way, did the developers prevent theSERIES_TERMINAL_FIRSTDATE identifier

return:

-1 - no data

0 - no data available, but not ready

> 0 - date itself.

And what is the difference between "not available" and "not ready" for the program (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.

123456789101112131415...31
New comment
Reason: