Typical mistakes and how to deal with them when dealing with the trading environment - 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
We've already discussed it. it's not going to be universal, because one needs one thing and the other another another.
I call for a return to reality. And if there is uncertainty in the form of a market order, then either you wait for its result and return what has already happened, or let the program decide how to handle it. But certainly not to return a quantity on the off-chance.
It's not a quid pro quo, it's the way it is. There are two positions fully available for change and one frozen (no change). There are three positions in total. This fits in well with the MT4 logic that you have taken as your reference.
If the MC had done a normal synchronous operation, there would have been no such questions at all.
Moreover, fxsaber has explained why he does it the way he does and why he is not satisfied with my logic.
Forum on trading, automated trading systems and trading strategy testing
Typical mistakes and how to fix them when working with a trading environment
fxsaber, 2018.02.24 16:25
I'll even show you what such cancelled market orders look like
Only there is no error.
This example turned out to be much cooler. A TP placed by the broker itself got coded! And almost immediately (I was waiting for 115 ms - apparently it was a bug of MT5) after the re-order was closed, the broker set another TP, which was executed. The comments to the orders did not show up in the screenshot. Green colour isORDER_REASON_TP. Accordingly, the reject order even has an ORDER_POSITION_ID.
If the MCs made a normal synchronous operation, there would be no such questions at all.
Such OrderSend can be written by the coder himself. When I use synchronous OrderSend, this is the solution I use.
It should be understood that the MC's could get a timeout if they write it themselves. Logically, the MC is not responsible for market orders sent to a third party system.
Tried very hard, but still couldn't figure out where 2 + 1 != 3 is important.
ZZZ there is also an asynchronous variant. And there it's quite possible to run into a market order. So such a position counting function would be relevant even if the MCs made a "normal synchronous operation".
This OrderSend can be written by the coder himself. When I use a synchronous variant of OrderSend, this is the solution I use.
However, it should be understood that the MCs could get a timeout if they write such a solution themselves. Logically, the MC is not responsible for market orders sent to a third party system.
Tried very hard, but still couldn't figure out where 2 + 1 != 3 is important.
Nah, not like that. In your case: 2 + 1 - 1 = 3
I realise we have different arithmetic. Probably shouldn't continue. But influencing the Buy More to stop posting code with bugs would be worth it.
I realise we have different arithmetic. Probably shouldn't continue. But it might be worth it to get the QB to stop posting buggy code.
Tried very hard, but still can't figure out where it's important that 2 + 1 != 3.
when the strategy implies an immediate reaction to an open position. in this case the redirect can break the logic.
In the vast majority of cases, any accounting (both the order as a position and the order as an intermediate, non-working state) will take away the problems.
Such OrderSend can be written by the coder itself.
strange logic, i can write the terminal that way too. after mt4 it looks like shifting problems to the coder's head. and so many things.
when the strategy implies an immediate reaction to an open position. in this case the redirect can break the logic.
I'm afraid that's crooked logic. But I could be wrong, of course. It would be interesting to hear the logic.
strange logic, i can write the terminal that way too. after mt4 it looks like shifting problems to the coder's head. and so on with a lot of things.
I guess it's still a matter of uninformed or weak Documentation. I think if everything was well explained there, there would be fewer errors and such conversations. But that's probably what this forum is for. Because it is obvious that it is impossible to take into account everything in documentation.
ZZY The source code of my ready-made solution was posted in the public domain.