Servicedesk: laziness, autism or unwillingness to admit mistakes? Supplementing the charts with non-native candles. - page 8
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
I take it someone is deliberately throwing hysteria with the idea "there might be something else instead of minutes".
The facts are this:
Please bear in mind that products brought to market are a collection of compromises.
Maximalism in defending the purity of one theory inevitably comes into conflict with a dozen other positions. And the winner in the end is most often the cumulative compromise, where each side has to sacrifice something little by little.
Deliberately and deliberately, in order to make the functions
SERIES_BARS_COUNT
Numberof bars per symbol-period at the moment
long
SERIES_FIRSTDATE
The earliest date per period-symbol at present
datetime
An identifier that determines if it is a real minute or is it a deliberately and deliberately set bar higher than the current timeframe - you couldn't think of one?
About other DTs, there is no need to worry about
SERIES_BARS_COUNT
Amount of bars by symbol-period at the moment
long
SERIES_FIRSTDATE
First date for the current symbol-period
datetime
means that historical start dates can be different for different timeframes. How could this not raise the question "If everything is stored in minutes then we cannot get the start dates by date of the first bar, may we use identifier? And by the way, is it me who thinks that everything should work like clockwork on developer's servers and third-party brokerage companies should have bugs? Why go off with phrases like "it sucks here, let them do it well"?
Anyway, the fact remains that the functions do not match the description...
I'll self-destruct.
I'll join in. The reasons for MK's arrogance and aggression are not clear. There was excellent feedback, which, by the way, allowed the company to save not small money.
And it is not about that forum people do not take into account much, it is true, I am talking about the fact that this weekend minus two. We put the Composter on the spot and mildly criticized the Expert.
It is difficult to underestimate the contribution of these two forumers in recent years. But the gopota feel great and can safely lay on the public moderators.
Of course, you can press the "complain" button, but it either does not work now or varies with the course of the party. But gopota not ask how can be on the chart of one period candles from another.
It is also possible to broadcast candlesticks from other instruments in order to increase the informativeness.
I will join in. The reasons for the MK's arrogance and aggression are not clear. There was excellent feedback, which, by the way, allowed the company to save a lot of money.
From my point of view it was an escalation of an insignificant problem where people joined in a friendly shouting match.
Our decision was informed. I gave an explanation, but someone really likes to play "theories to the end".
I am not talking about the fact that the forum people do not take into account, of course, but I am talking about the fact that this weekend we got minus two. The Composter has been misunderstood and the Expert has been gently lambasted.
It is difficult to underestimate the contribution of these two forumers in recent years.
Firstly, you're attributing to me something I didn't say. Secondly, they definitely have very little information, concentrated on one side only.
Also note the wording of the topic and the epithets lavished on us.Is it not clear?
Option 1) Add to the history file additional parameter Basef - if the bar is really a minute one, then 0 if there is no minute one, but there is an hour one, for example, then the parameter = 60 if the daily one, then the parameter = 1440.
Anton, the bars are ALL minute bars. The entire history is stored on the server only as minute bars. The other TFs are built based on minute bars when loaded into the terminal.
The fact that you see a daily bar in the minutes until '99 - it means that this bar "daily" is included in the minutes. It is there. You see?
a) when loading a chart, we check it and, respectively, prohibit displaying of non-native bars, etc. up to the date
b) check it once and record all stitch points separately (the history will not go anywhere)
variant 2) store only info about stitching points (to save space, although I think these days variant 1 will not take up hard drive)
where do you store it? how do you manually control it? how do you fill the history file?
From my point of view it was an escalation of an insignificant problem, where people joined in a friendly shouting.
Our decision was a conscious one. Explanations have been given, but someone really likes to play "theory to the end".
First of all, you're attributing things to me that I didn't say. Secondly, they certainly have very little information, concentrated on one side only.
Also note the wording of the topic and the epithets lavished on us.You admit that there is a problem, so let's fix one insignificant problem, then another and then a third, and the terminal will be better.
Community represented by many people initially gave you conceptual ideas for development (gratuitously, ie for free), you have stated that do not get into the concept, we have ambitious plans, you do not know them and so on.
Okay, we moved on to the identification of specifics that we do not like, where we can improve.
Now you say you do not need to get into specifics, but in fact do not get anywhere, use the terminal as is and do not bother MQ brain.
Well, Caesar to Caesar.
I take my leave now, it's boring here.
Did anyone come across any daytime bars on minutes other than 01.01?
You can see by the size of the history file
Did anyone come across any daytime bars on minutes other than 01.01?
You can check the size of the history file
There is no access to the history file size in MQL5, and this is an indirect estimation.
If not on the Day, then the M5 will be added. After all, the addition takes place on different timeframes, from lower to higher.
The question is clear. We need dates of gluing by means of MQL5. The proger will decide by itself up to which TF the gluing is not critical.
You admit there is a problem, so let's fix one insignificant problem, then another and then a third and the terminal will be better.
The question is clear: you need dates of gluing by means of MQL5. The proger will choose the date up to which TF the gluing is not critical.
Where to store, how to record, how to control/change them?
Why do you think everything will go from the oldest to the oldest?
it is difficult to do.
my advice is don't use the history and terminal from the MC server. find a broker without that silly gluing.
where to store it, how to write it, how to control/change it ?
How many stacks can there be? Why do you think everything goes from junior to senior?
it's hard to do.
my advice is don't use the history and terminal from the MC server. find a broker without this silly gluing.
Dilling gives the original story, and the Dilling is the one who corrects it. MQ just needs to make a mechanism for creating such a story from other formats, and that's where the mechanism is flawed.
I made an assumption that history is stitched together from junior to senior, but it's logical (correct it if you're wrong).
The introduction of additional information in the history file that this file has a glue point, it's just an extra feature, everything will be usurped by the old, but still appear a simple way to identify the desired location progeru and that's all.
I honestly do not understand why MQ has such a problem.
SZY where to store can tell you, in the file is an area in which the encrypted name of the instrument is there and encrypt this information.