Errors, bugs, questions - page 2219
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
Result onForexTimeFXTM-Demo01
The script opens and closes positions until it detects a "phantom order" - neither among the current ones nor in the history. Should I consider it a bug or a platform feature?
ZZY The script is written in such a way that several positions may open because of this nuance. But it does not prevent from getting a "phantom order".
I don't want to be nerdy, but expressions like these:
You may remember by heart all the numeric values of a given enum and in what order they go, but other people may not know these guts. You should not handle an enum this way. Brevity is certainly the sister of talent, but only if it does not damage the quality.
And speaking of the matter under discussion, the order.deal, not the result.order, should be checked for the position to be opened. Accordingly, it must be found among positions, not orders. Isn't it so?
Shortness is, of course, the sister of talent, but not to the detriment of quality.
It seems to be a common MQL operation.
And speaking of the matter under discussion, the order.deal, not the result.order, should be checked for the position to be opened. Accordingly, it should be looked for among positions, not orders. Isn't it so?
The initial order that is sent immediately after OrderSend might not be found anywhere. The position is much later than the order.
ZZY In the code, I purposely left the comment with the most understandable language of trading algorithm - MQL4.
The original order that is sent immediately after OrderSend may not be anywhere. The position is much later than the order.
It's not the point, in fact, according to documentation, OrderSend doesn't have to receive any tickets:
When sending a market order (MqlTradeRequest.action=TRADE_ACTION_DEAL) the successful result of OrderSend() function does not mean that the order has been executed (corresponding trades have been executed). In this case true means only that the order has been successfully placed in the trading system for further execution. The trading server may fill the values ofthe result fieldsin the returnedresult structure, if these data will be known to it at the moment of OrderSend() call generation. In general case, the event or events of deals corresponding to an order can occur after the OrderSend() call response has been sent. Therefore, for any type of trade request, when receiving the OrderSend() result, you must first check the trade server return coderetcode and external trade system response coderetcode_external(if necessary) available in the returnedresultstructure.
So, we cannot do without OnTradeTransaction in any case.
So, it turns out that there is no guaranteed synchronous trade operations in MQL5.
It doesn't really matter, because according to the documentation, OrderSend is not obliged to receive any tickets:
You don't have to check it in any case. It's only optional.
A non-zero Result.order after the synchronous OrderSend tells us always that a response is received from the trade server with an order registered on it. This ticket comes exactly from the server. And if OrderSend is successful, this ticket is always received.
The bummer, however, seems to happen not because of OrderSend, but at the moment of accepting the order into a trade. Although there isORDER_STATE_REQUEST_ADD for such cases. Anyway, waiting for an answer from MQ. In my opinion, this is a bug when there is an order on the trade server, but after synchronous OrderSend on the terminal there is no word about it.
Anyway, waiting for a response from MQ. In my opinion, this is a bug, when there is an order on the trade server, but after synchronous OrderSend on the terminal there is no sign of it.
I say more, we should ask the developers to ensure full synchronism of OrderSend, both on the terminal and on the server. Otherwise, if the synchronism of execution is not guaranteed, then why do we need this function? For this purpose there is already OrderSendAsync.
Hello. Today I updated to version 1860 and while optimising the Expert Advisor I encountered this problem:
The delay between passes is 1 minute! Can you please advise what may be the problem?
p.s. Before the update everything was working like clockwork.
Are you using the Bars function, by any chance?
If so, see this.
Just a question:
Maybe it makes sense to make common files? The only thing that bothers me is constant renaming of mq4 and mq5. In connection with the projects, I was thinking, maybe I should make a common extension like mq ?
And you can just copy code from terminal to terminal without any edits in extensions...
Just a question:
Maybe it makes sense to make common files? The only thing that bothers me is constant renaming of mq4 and mq5. In connection with the projects, I was thinking, maybe I should make a common extension like mq ?
And you can just copy code from terminal to terminal without any edits in extensions...
And who forbids to write these codes in mqh files and connect them using (#include). That's what I've been doing for quite some time.
And who forbids to write these codes in mqh files and connect them with (#include). Which I have been doing for quite some time.
you plug in, I change the extensions ... neighbours.
I say more, we should ask developers to ensure OrderSend is fully synchronous, both on the terminal and on the server. Otherwise, if synchronous execution is not guaranteed, why do we need this function? There is already OrderSendAsync for this purpose.
Let me get this straight. Synchronization of ORDER posting to the trading system of the platform and the terminal itself.