Errors, bugs, questions - page 3036

 
Anton:

This is provided by the terminal.

Yes, it does.

Anton, a separate function to get all M1(only M1) regardless of MAX_BARS parameter without caching and saving data to disk is very missing. This would give the programmer new opportunities to form his own historical data structure.
All ticks are accessed, but M1 is not if MAX_BARS != Unlimited. The issue wouldn't arise if all ticks covered all of M1's history, but they don't.
 
Nikolai Semko:
Anton, really lacks a separate function to get all M1(only M1) regardless of the MAX_BARS parameter without caching and saving the data to disk. This would give the programmer new possibilities to form his own structure of historical data.
All ticks are accessed, but M1 is not if MAX_BARS != Unlimited. The question wouldn't arise if all ticks covered all of M1's history, but they don't.

it remains to be seen how many users or programmers will use this? - turn on the Unlimited chart properties in the terminal settings and use

so far it looks like "the developer come and turn on the Unlimited setting for me if you don't make new pluses"

 
Igor Makanu:

the only thing left to figure out is how many users or programmers will use it? - turn on the Unlimited chart properties in the terminal settings and use

so far it looks like "the developer come and turn on the Unlimited setting for me if you don't make new plushies"

Unlimited is a very expensive option for the whole terminal. Immediately the disk space and traffic consumption goes up gigantically. But if Ionly needUnlimited for one tool and only once?
After all, my file storages of historical data take 5 times less disk space compared to regular ones, and at the same time they are more informative, because they contain time for High and for Low and all already calculated TFs and you don't need to calculate them every time on the fly.

I assure
you, Igor, that if I publish such a library in BE, many programmers will start using it or create something similar looking at its effectiveness.
And if it's also a product in the Marketplace?
Do I have to ask everyone to enable thisUnlimited, knowing that by doing so I will put them very much on traffic and disk space?

I think my request is perfectly adequate, and that it doesn't require a lot of resources to implement, as everything already exists as it is. It's a 10-15 min matter.
After all, when max_bars = 1000 and you request 1000 W1 bars, the whole M1 history is loaded anyway, and W1 is already calculated from it, only M1 is not saved to file.

 
Nikolai Semko:

Because when max_bars = 1000 and you ask for 1000 W1 bars, the whole M1 history is still loaded and W1 is already calculated from it, only M1 is not saved to the file.

How is it? Loaded, but not saved?

 
Andrey Khatimlianskii:

How's that? Loaded, but not saved?

Only M1 is loaded from the server, and any other TFs are generated from it.
No more than max_bars of those TFs that were requested programmatically or by the user through TF selection are saved to disk.
1000 bars W1 is about twenty years of data, i.e. almost the whole history of M1 will be loaded.
You can Andrei check my words. Open a new symbol in the market overview and open its window and turn on the monthly TF right away. And you'll see how fast the data is being downloaded.
But you will see a small file in ...MetaQuotes\Terminal\...\bases\...\history\...\cache\M1.hc.
And the funny thing is, the hcc files will be generated over all the years and will already weigh up to half a gigabyte. The hcc format means that they are already downloaded by M1, but unavailable to the programmer.
So you won't have to download them either.
And judging by the size of the MqlRates structure = 60 bytes, the hcc files are not packed at all. Very wasteful!

HZ made an experiment more attentively and found out that when requesting data of any periods, the unpacked data of these periods are saved in hcc files (minute bars) and data are unpacked from RAM into Cache catalogue only at terminal shutdown.
I.e., timeframes are formed and calculated in memory and saved to file cache at terminal shutdown. That is actually logical. It is only illogical to keep hcc files in unpacked form and not to give access to them for programmers.

 
Nikolai Semko:

well, if that's what it takes, just wait, provided the developers see sense in it.... just be prepared to wait for, well... I asked about operator overloading, the admin said it was an unnecessary feature, then I haven't dealt with MQL for 5 years and now everything is here! ))))

 
Igor Makanu:

well, if you have to wait, just wait, provided the developers see sense in it.... just be prepared to wait for, well... I asked about operator overloading, the admin said it was an unnecessary feature, then I haven't dealt with MQL for 5 years and now everything is here! ))))

Yes, it's a sad sight. I agree.
The reason, as I said before, is the manual management of the company.

 
Anton:

This is provided by the terminal.

Yes, it does.

Nikolai Semko:
Anton, what is very missing is a separate function to get all M1 (only M1) regardless of MAX_BARS parameter without caching and saving data to disk. This would give the programmer new possibilities to form his ownstructure of historical data.
All ticks are accessed, but M1 is not if MAX_BARS != Unlimited. The question wouldn't arise if all ticks covered all of M1's history, but they don't.

i.e. from the above the request can even be simplified:
Get programmatic access to already existing M1 bars located (downloaded) in hcc files. You can do it with a separate command or with already existing ones.
If I need minute bars beyond max_bars, then I just need to initiate MN or W1 bars download, and after that I will be sure? that the necessary hcc files have already been generated.

 
i.e. do you want the inherent ability to bypass the inherent restriction? )
 
Andrei Trukhanovich:
So you want an inherent ability to bypass an inherent limitation? )
It's not a limitation.
There is no point in restricting it.
Security is not affected. Nor does it affect any kind of resources; on the contrary, there is an opportunity to save resources for programmers.
This is a simple illogism, which I propose to correct.
You have the data, but you can't access it.