![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Gentlemen of the prog...
You wouldn't know about it on mt4 ?
You use the predefined Ask Bid yourself ?
In mt5 for the entireMqlTick structure they are missing for some reason.
Call the function, fill the structure, and only then get the value.
Or immediately get the value, is there a difference?
Or it is not in my direction?
You should at least indicate who you are writing to ))
Predefined variables, for the current tick, would probably be better.
The developers have previously explained that there is a fundamental limitation to direct access
and in general, t1 is not equal to t2. Moreover, field values inside both t1 and t2 may end up referring to different ticks at all
The developers have previously explained that there is a fundamental limitation to direct access
and in general t1 is not equal to t2. Moreover, field values inside both t1 and t2 can refer to different ticks, even though they are linked fields (they should refer to the same tick).
Brr, what's the fundamental limitation?
The structure in your example is unnecessary, it doesn't need to be filled.
A value came from the socket and was written into variable _Ask, _Bid, etc. according to the structure.
_Ask != _Ask according to you?
A restriction occurs if you fill the structure, which takes some time.
You don't need to fill it, but give_Ask, _Bid, etc. directly.
Brr, what is the principle limitation?
The structure in your example is unnecessary here, it does not need to be filled in.
You can rewrite it without the structure. In general case ask1 is not equal to ask2
You can also rewrite it without the structure. In general case ask1 is not equal to ask2
I.e. these are requests to the non-synchronous environment, and the response is received by the current state of the environment? And OnTick is catching the current tick and working out the EA, but at the same time requests by the tick structure when the EA is working out can get answers from the next ticks?
You can also rewrite it without the structure. In general, ask1 is not equal to ask2
So you don't have to use 100500 digits, where the last digit of a real number differs 0.0000000000000000000001
For each variable a different digit, for price double maximum 8.
Released beta 2652, of importance:
22% good.
SymbolInfoTick - on my home machine, I noticed by eye that it didn't alerts. However, did a filter on these alerts in the Log and saw that there were many more than the 2650 issued during the same period twenty-four hours ago.
Sent both logs to the PM.
I.e. these are requests to a non-synchronous environment, and the response is based on the current state of the environment? And OnTick is catching the current tick and working out the EA, but the requests by the tick structure when the EA is working out can get answers from the next ticks?
Yes.
For mass ticking work, put in more memory.
4gb (price €20) is nowhere near good in 2020 when it comes to analytics and research.
We are talking about a one-off call to CopyTicks. It's done in order to make a virtual backtest on these ticks in OnInit, and then to continue it in real-time, feeding only fresh ticks.
As a compromise, I propose to release the memory in the Terminal immediately after the CopyTicks called in OnInit. Then we don't have to introduce a forced cooling function for CopyTicks.
Right now Sleep-version of cooling is very crutchy. But I showed above how this crutch saves memory.
Now it turns out that 20 Expert Advisors run fast even on slow VPS. But starting them up is a serious problem.
Here is an Expert Advisor that shows the problem.
Result.
22% - fine.
SymbolInfoTick - on the home machine I noticed by eye that there were no alerts. However, did a filter on these alerts in the Log and saw that there were many more than the 2650 issued during the same period twenty-four hours ago.
Sent both logs to the PM.
Acceleration by a factor of ten in cases of mass parallel access.
For other cases only processor, memory and operating system upgrade.