Servicedesk: laziness, autism or unwillingness to admit mistakes? Supplementing the charts with non-native candles.
Is this the question you raised a month ago? https://www.mql5.com/ru/forum/1111/page878#comment_344461
FiftyStars:
...The story is what it is. We don't have a deep minute history. For your convenience, the deeper history is represented by daily bars.
If it is not convenient for you, limit the use of this history manually.
The gist of the answer was already known at the time(https://www.mql5.com/ru/forum/1111/page878#comment_344518):
But I'm afraid that it (the answer) will be something like this: "The programmer himself can calculate the boundary date and limit the depth of the requested history.
I contacted Service Desk with a problem with attaching higher candles to low TF charts when there is no history on lower TFs. I.e. when we go to the beginning of history in the M1 chart, we see candles not from M1, but from D1, or even from W1. Because of this accession, the SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x) function returns not the date on which the M1 history ends, but the date of the first bar outside the timeframe, i.e. the specified timeframe does not affect the result.
...
SERIES_BARS_COUNT returns the number of candles (bars), belonging to a certain symbol and timeframe
SERIES_FIRSTDATE returns the date of the first candle (bar) opened, which belongs to a certain symbol and timeframe.
More info
...
The functions work correctly.
What you see is a consequence of your previous history quality request.
The history is what it is. We do not have a deep minute history. For your convenience, the deeper history is represented by daily bars.
If it is not convenient for you, limit the use of this history manually.
This is a frank excuse, the programmer cannot foresee all variants of history biting, so he can't prescribe the function of searching for the first date of the TF. Today they are like that, and tomorrow they will have new twists and turns, and without MQ's knowledge, for example dealing will screw something up.
And why do we need it when there is a standard function, but the fact that it gives the weather for the day before yesterday is already an outright bug.
Here's the crux of the problem for the programmer:
We need to search for variants of the criteria according to which this bar can be considered the first bar of the selected TF, and all previous ones - the addition from the older TF. There may be gaps in bars such as a missed bar (this is a direct consequence of MQ's chosen bar recording format) or gaps in bars such as weekend/holiday. And in such a cacophony of signs it is unclear how to determine that this bar is the right one.
What is the essence of the problem for MQ: (if we mean that they are going to solve it)
When history is sewn to a file encrypt data on the points of stitching (there are not many, maximum 21 by the number of TF, in practice, there are 2-3), the issue is solved. Next, write a function to read this protected information and output it to the user via request.
Thank you, don't decide for the traders.
What fresh head was it to make such a move after Friday - to insert the older bars in theM1 timeframe?
Who even gave you the right - to reverse many years of well-established principles?
If you are not comfortable with it, limit the use of this story manually.
Thank you, don't decide for the traders.
What fresh head was it to make such a move after Friday - to insert senior bars in theM1 timeframe?
Who gave you the right to reverse many years of established principles?
Alex, don't exaggerate, the TF gluing was needed to correctly calculate all other TFs, after they decided to calculate all TFs from M1.
If you remember, it let us calculate as many as 21 TFs (including non-standard ones).
It was not told about that more than once. We will not go back to the old system of storing each TF separately, you understand.
But the fact that the implementation adds more trouble for programmers is a fact. And the question is simple to solve, but no, we know better what you need :(
so that's what I'm wondering.
Если вам это не удобно - ограничивайте использование этой истории вручную.
Alex don't exaggerate, the TF gluing was needed to correctly calculate all other TFs, after the decision was made to calculate all TFs from M1.
It is solved by setting an identifier in the history and when reading, if the data for the bar does not belong to M1, then it will not be output in M1, not belong to M5, then it will not be output in M5. Or yes... we should write the date of joining bars of the current period with those of higher period in FirstDate and the user will have a real possibility to know which date to start processing from so as not to catch older bars.
The situation is certainly moronic.
You can neither draw such graphs, nor return such values from functions.
You want to build from M1, build it. Not enough M1 - figure out how to get out of it, but not at our expense.
(all addressed, of course, to MQ)
- www.mql5.com
I agree, it's rubbish.
And if there are period separators, it's a beauty.
And you have to twist it in the code ((.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
I contacted Service Desk with a problem with attaching higher candles to low TF charts when there is no history on lower TFs. It means that when we go to the beginning of history in the M1 chart, we see candles not from M1, but from D1, or even from W1. Because of this accession, the SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x) function returns not the date on which the M1 history ends, but the date of the first bar outside the timeframe, i.e. the specified timeframe does not affect the result. When asked, I received an excuse that it is convenient for users and the cut-off date for each timeframe of each symbol should be set manually. Excuse me, but shouldn't this function be performed by the function SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x), and how doesSERIES_FIRSTDATE differfromSERIES_FIRSTDATEin the specified TF M1if the result is the same?
What is this nonsense? Who and why is it convenient? No one wants to see W1 candles on M1 charts. Well, except for masochists ...
I come to the following conclusion: either the developers are autistic (they live in their world, where the above and below are the norm, or rather not the norm, but the work is 5 +), or they are too lazy to fix it, or the principle of "How come we are never wrong, we are all good". Well, there are also variants: they joke around, they don't know how to fix it.
Here are the screenshots, you can clearly see the joining line of the history of different TFs:
https://charts.mql5.com/1/26/eurusd-d1-metaquotes-software-corp-7.png
https://charts.mql5.com/1/26/eurusd-h4-metaquotes-software-corp.png
https://charts.mql5.com/1/26/eurusd-h1-metaquotes-software-corp-9.png
https://charts.mql5.com/1/26/eurusd-m30-metaquotes-software-corp-2.png
https://charts.mql5.com/1/26/eurusd-m15-metaquotes-software-corp-6.png
query 1:
Version and bit rate of the terminal
Build 712 x86
Problem description.
Historical data of small timeframes is continued by historical data of larger timeframes. It means, for example, that EURUSD history on M1 ends on ~04.01.1999, and to the left side of the M1 chart is attached D1 chart for the period before 04.01.1999.
In attached screenshots it is visible. Because of this, the SeriesInfoInteger function with the SERIES_FIRSTDATE parameter works incorrectly. The function returns the first date of the entire history (including timeframes D1, W1 and MN1) instead of the first date of the symbol-period.
The sequence of actions
Scrolling through the chart to the beginning of history
The obtained result
Continuation of the chart with historical data from larger timeframes.
Expected result
Restriction of the chart at the end of the history data on the given timeframe.
Additional information
Request 2:
Terminal version and bit rate
build 712 x86
Description of the problem
Description in documentation:
SERIES_BARS_COUNT.
Number of bars per symbol-period at the moment
long
SERIES_FIRSTDATE
The first date for the current symbol-period
datetime
Because of the accession of the history for the lower TF, in the case of the absence of history for a specific period of time on the lower TF, and the presence of history for the same period on the larger TF, the chart, for example, M1 shows candles from the chart of D1.
Is a solution to this problem being prepared? Are there any solutions of this problem at the moment, other than manually restricting?
Sequence of Actions
Using these functions
The obtained result
SERIES_BARS_COUNT on low timeframes (up to D1) returns the number of candles (bars), belonging to the symbol and timeframe, plus the number of candles from the nearest bigger timeframe, for which the historical data is available
SERIES_FIRSTDATE on low timeframes (up to D1) returns the opening date of the first candle (bar) in the history.
The expected result
SERIES_BARS_COUNT returns the number of candles (bars), belonging to a particular symbol and timeframe
SERIES_FIRSTDATE returns the date of the first candle (bar) opened, which belongs to a specified symbol and timeframe.
More info
...
The functions work correctly.
What you see is a consequence of your previous history quality request.
The history is what it is. We do not have a deep minute history. For your convenience, the deeper history is represented by daily bars.
If it is not convenient for you, limit the use of this history manually.