Features of the mql5 language, subtleties and tricks - page 93
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
That's what WinAPI does.
I disagree.
WinAPI does not react to local time correction, unlike GetMicrosecondCount.
I disagree.
WinAPI does not react to local time correction unlike GetMicrosecondCount.
This is because our time is shown not as absolute time, but as a delta from the start of the program:
The GetMicrosecondCount() function returns the number of microseconds elapsed since the start of the MQL5 program.
Since the counter value is fixed at application start, this delta is affected by date changes. Seriously changing the date on your computer when there is time-dependent software working - this is sabotage and approach of Russian guys with a Japanese chainsaw. For the sake of an anecdote, that will do.
The justification "well, the background time corrector works" does not fit here - its correction milliseconds per day and it has no effect.
The microsecond timer is needed for accurate measurement of small periods, not for counters from the beginning of times.
I disagree.
WinAPI doesn't react to local time correction, unlike GetMicrosecondCount.
and how do you see the practical application of GetMicrosecondCount that it spoils the whole work of the program in the current version? describe the practical application
for example, neither in C++, nor here, i do not see variants other than those described by Renat, i.e. measuring code execution time with accuracy in mcs
I don't understand your persistence, frankly.
Since the counter value at the start of the application is fixed, this delta is affected by the date change. Seriously changing the date on a computer when time-dependent software is running there is sabotage and the approach of Russian men with a Japanese chainsaw. It will do for an anecdote.
I purposely showed the animated gif with the time synchronization on the Internet. Such synchronization is automatic by default and it happens quite often and according to schedule without anybody's participation.
And there is no guarantee that at the time of measurement can happen this synchronization.
I am not worried about myself, because I already know about this feature of GetMicrosecondCount() and that this function is slower than GetTickCount.
But other people, who will not read this branch but read the help for this function even very carefully, may run into trouble if they use GetMicrosecondCount() in the real EA operation logic, because during testing everything will be OK, but during real trading at the time of planned time synchronization or switching to Summer time there may happen OY, especially if the time decreases and overflow like ulong occurs.
And by the way, this new to me undocumented information, made significant adjustments to the logic of the multitimer class, which is created now and which organizes the operation of several timers simultaneously. In the work of this class, the microsecond function was used at its best. But now I understand that I will have to sacrifice precision of 15625 µs in order to increase its speed.
Faber is a plie. He's not mean, he's just pushy, but he's good.
Man, I'm going to get banned too :((
Because we do not show the absolute time, but the delta from the start of the program:
Since the counter value is fixed at application start, this delta is affected by date changes. Seriously changing the date on the computer when time-dependent software is running there is sabotage and the approach of Russian men with a Japanese chainsaw. For the sake of an anecdote, it'll do.
The justification "well, the background time corrector works" does not fit here - its correction milliseconds per day and it has no effect.
Microsecond timer is needed for precise measuring of small periods, not for counting from the beginning of time.
That is, it makes sense to periodically restart the terminal?
I specifically showed the animated gif to show the time synchronization over the Internet. Such synchronization is automatic by default for everyone, and it happens according to the schedule without anyone's participation and quite often.
I wrote explicitly and clearly - daily correction by milliseconds automatically.
And yes, you'll be just as blown away by a pure WinAPI function (either GetTickCount or QueryPerformanceCounter) when you slip a scrap into the chainsaw by changing the date even by seconds. There's no protection at all that you're talking about supposedly having. Sucked out of thin air as a problem and alleged solution.
So everything is correct - this is how WinAPI is and this is the reality.
So it makes sense to periodically restart the terminal?
No.
I have a week candle close time counter begins to rush for 5 seconds, I thought that this is a matter of the program.
It helps to restart and synchronize the time with the service corresponding.
The battery on the mother changed not so long ago.
I have a week candle close time counter begins to rush for 5 seconds, I thought that this is a matter of the program.
It helps to restart and synchronize the time with the service corresponding.
The battery on the mother changed not so long ago.
Set up a regular Windows Time service to synchronize every night (or more often) with pool.ntp.org and the daily correction will be in milliseconds.
It is configured, but it does not help - I do not understand the reason. True, my server is ntp2.stratum2.ru