MetaEditor build 1490 - page 6
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
https://www.mql5.com/ru/forum/162399/page3#comment_3894115
For some time now, when a position is flipped its Position ID is CHANGED. This is shown in the help. Hence the inconsistencies.
That's not the problem.
Service Desk said they will fix it, a fix will be available in today's build.
Service Desk has replied that a fix will be available in today's build.
1491 - has not been fixed.
Unfortunately - no.
By the way, it is not at all clear how the current position accounting system will separate the part of the position which closed the previous position and the remaining part of the new position (this division does not exist at present). It seems that the problem is deeper than it may seem at first glance.
Unfortunately - no.
By the way, it is not at all clear how the current position accounting system will separate the part of the position which closed the previous position and the remaining part of the new position (this division does not exist at present). It seems that the problem is deeper than it may seem at first glance.
Forum on trading, automated trading systems and strategy testing
MetaEditor build 1490
fxsaber, 2016.12.05 11:32
Yes even ifDEAL_ENTRY_INOUT is included in the number of trades of the position, it will be of no use unless you expand ENUM_DEAL_PROPERTY_*.About the same
In my opinion, on the contrary, the enumeration should not be expanded, but shortened. SoDEAL_ENTRY_INOUT is an unnecessary entity that does nothing.
Here is an example of what it looks like now
IN; +1.0; ID 0
IN; +0.2; ID 0
IN/OUT; -2.0; ID 1 // a new position with a new ID has been created but there are no trades in it; all the trades refer to the previous position; therefore the commission and swaps are 0.0
IN; +0.2; ID 1 // the first trade appeared in the list and it is the only one
thus a part of volume did not move to a new position and is not displayed anywhere, therefore swaps and commissions will not be taken into account for this part of volume in the position ID 1 (blue and green corresponding lists of trades)
Now how I see it, and how it should be logically and historically (what decision MQ will make is anyone's guess):
IN; +1.0; ID 0
IN; +0.2; ID 0
OUT; -1.2; ID 0 // the part of the deal volume that has gone to the position being closed
IN; -0.8; ID 1 // a new position has appeared with the new ID, the trade is present as the remainder, the trade is in the list, and it is the first
IN; +0.2; ID 1 // the second trade in the list
Thus, the type of deal IN/Out is not needed at all. In this way everything is considered correctly and the lists of deals are complete, we can adequately obtain the values of commissions and swaps for the corresponding deals. And if there will be a necessity to determine which deals (one part went to closing and the other to opening a new position) are part of one order, it will be very easy to do so - OUT and IN deals having the same time (marked in bold).
In my opinion, on the contrary, the enumeration should not be expanded, but shortened. SoDEAL_ENTRY_INOUT is a superfluous entity that does nothing.
A transaction is an execution entity that does not depend on platform. And ENTRY flags are an MQ nonsense.
If there was one trade in the market, you can't represent it as two, even though it would be convenient.
MQ have gone out of their way to add virtualisation - Hedge mode. Doing even a simple virtualisation for an exchange is a bad decision.
But extending the transaction properties gives convenience without the potential crutches.
A transaction is an execution entity that is in no way platform-dependent. And ENTRY flags are an MQ contrivance.
If there was one trade in the market, you can't represent it as two, even though it would be convenient.
MQ have gone out of their way to add virtualisation - Hedge mode. Doing even a simple virtualisation for an exchange is a bad decision.
But extending the properties of the transaction gives convenience without potential crutches.
Well I was just stating my opinion.
And what kind of extension would save the day? You still need to somehow determine which part of the transaction relates to the old position and which to the new one.
And what kind of expansion would save the situation? There is still some way to determine which part of the deal is for the old position and which is for the new one.
1491 - Alpari-MT5-Demo. The screenshots show the same place
Terminal
Real tick tester
The candlesticks do not correspond to each other - in the tester they are fuzzy. Moreover, historical time of the tester and the terminal differ by one hour.
CopyTicks in the terminal returns the same data as in the tester - one hour difference. Therefore, the ticks do not match the bars completely.
So how to trust MT5, the tester, when there is a complete self-discredit? Why don't the developers have benchmark EAs to run in the tester and know for sure that it works clearly? It's a complete mess.