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 have highlighted the key words.
Do NOT request ticks that do not already exist by definition. If you request ticks even one millisecond beyond the current time in milliseconds, you will get the very g.........y in the form of the problems you listed.
So, in your understanding, I should check firstly, whether these ticks are available? for example how? can I also check, whether the requested range is on holiday? it must be done by function CopyTicksRange() . My job is to give it the input parameters according to the documentation. And it can check them, and if anything, return an error, but not some rubbish in the response.
Can you think of a way to check if an existing bar contains ticks from second to third second, to prevent this function from crashing?
Above I wrote a code example where everything is there, but the answer is still wrong.
So, in your understanding, I should first check if these ticks are available? How, for example? Should I also check if the requested range is on the day off? This should be done by CopyTicksRange() function . My job is to give it the input parameters according to the documentation. And it can check them, and if something happens, it will return an error, but not some rubbish in response.
Above I've written a code sample where everything is present, but the answer is still wrong.
SymbolInfoTick
Returns current prices for a specified symbol in a variable of MqlTick type.
You don't need to query ticks further than time_msc
1)In my example above requested range exists.
2) but what prevents from making this check inCopyTicksRange itself and reflect it in documentation as well? why developers ask me to make crutches instead of simple fixes of their errors?
Speaking ofSymbolInfoTick - it works wrong too, at least forsynthetic characters :)
As I remember, it always returns the time of the very first tick instead of the last one
As far as I remember, it always returns the time of the very first tick instead of the last one.
I don't take part in this dialog anymore.
I am no longer participating in this dialogue.
You are not a Metatrader developer either, why have you taken on the role of their advocate?
One line back to the dialogue:
The function should work the way the developers intended, not the way the users want it to work. One wants one thing, one wants another, and one wants nonsense.
This is the reason the developers don't respond to you. And I am not a lawyer, I am trying to bring you a simple truth, do not disgust others if you can not do it yourself. You, on the other hand, have turned on the "don't......... give in..." and are making up myths about crutches.
That's really ALL¡¤¡¤¡¤ Developers won't answer you... don't get your hopes up.
And here's the bug:
i.e. the function used by thousands of programmers, has personally returned to me all ticks from the beginning of the current bar, but not included in the requested range
This is indeed a bug. Provide the full data for playback. If confirmed, the developers will make a fix in the next builds.
Perhaps the problem is in the MqlTick static array.Alexey Viktorov #:
No need to request ticks further than time_msc
Last historical tick may be more recent than SymbolInfoTick (called after CopyTicks). I run into this on a daily basis.
The opposite situation can occur. Flows that are not synchronized.This is indeed an error. Provide full data for replay. If confirmed, the developers will make a fix in the next builds.
Maybe, the problem is in static array MqlTick.Ok, I will try to reduce code to the minimum and post it. CopyTicks also contains such glitches but they occured there in less predictable way which lead me to crutches only for CopyTicksRange. Probably it's an error of some common internal function.
I will draw you an example for SymbolInfoTick too.
function used by thousands of programmers
Units.