Acceptance of SL/TP orders - page 7
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
ZZY I have already described above losing orders in previous posts, and now I would like to add the following one. The price reached the take point of an open position. The server has generated the corresponding TP-market order and delivered it to the terminal (Expert Advisors have seen it). Then this TP-market order disappeared not only from the Terminal, but also from the Server.
Architecturally, it goes like this.
The check may fail if, for example, there was a TP trigger of an open position, which is already in the closing state.
Thus, we can see the current full orders in the terminal (they will pass the check and will be in the trading history (even in the case of re-jects)) and phantom orders (they will not pass the check and will be absent in the trading history). Both of them will have their own tickets. Theoretically, the phantom orders could have the same tickets.
This scheme is designed due to the asynchronous architecture of the MT5 server. It somewhat resembles the OrderSendAsync logic from the Terminal. It is hard to say whether the server correctly sends information about phantom orders to the terminal before checking for correctness.
Feature TP.
TP feature.
Technically, there is no contradiction here: The TP in the example is set earlier than the limit order - that's why it is executed earlier. The TP is executed in a strange way in Ж-that's another issue
If we first open a position, then the TP is set and only then TP is executed, the result would be the same - then we have much to think about.
Technically there is no contradiction here: The TP in the example is set earlier than the limit order - that's why it is executed earlier. But the TP is executed in a strange way - that's another issue.
If we were to open a position first, then place a Limit order and only then TP, the result would be the same - then we would have a lot to think about.
This example is for illustration. The conclusions are not from the example.
The example is for illustrative purposes. The conclusions are not from the example.
So make an example where the error is obvious - it is clear that, all other things being equal, it is not normal if TP is executed earlier than the limit order preceding it
So make an example where the error is obvious - it is obvious that, all other things being equal, it is not normal if TP is executed earlier than the Limit order that precedes it
I don't need proof. MQ knows how it works.
I don't need proof. MQ is aware of how it works for them.
I doubt they are aware of the details. I remember being argued for several pages that there was no error (it was still a practice back then), then (after several more pages) they admitted that something was wrong - they decided to look into it
And if there is no specific, unambiguous example, then (in today's realities) consequently there is no reason to look into it
And if there is no concrete and unambiguous example, then (in today's realities) consequently there is no reason to look into it.
An example does not always give a reason to deal with it. MQs simply do not see the problem, or it is seen as irrelevant.
An example does not always give rise to an issue. MQs simply do not see the problem, or it is seen as irrelevant.
A significant problem is only if: TP fails to execute (price is gone - no time) and as a consequence the limit will also fail to execute
By the way, yes, it is interesting. If a small limiter is on the same level as the TP of a huge position, and that TP is redirected because it's big, the limiter won't even have a chance to fill?
This can be manipulated, I guess.