OrderSend() questions - page 8

New comment
 

While we are waiting for an article on this subject, do I understand the general concept of trade operation analysis correctly.

...
bool AllowTrade = true;
ulong OrderTicket;
...
void OnTick() {
  ...
  if (!AllowTrade) return;
  ...
  MqlTradeResult Result;
  if (OrderSend(...)) {
    Ticket = Result.order;
    AllowTrade = false;
  }
}
...
void OnTrade() {
  if (AllowTrade) return;
  if (OrderSelect(Ticket)) {
    if (...)
    ...
    // AllowTrade = true|false;
  }
  else AllowTrade = true;
}
...

I.e. roughly speaking, after sending an order without analyzing the retcode, we prohibit trading operations in the work loop (OnTick()) using the "AllowTrade" flag.

The trade ban is only unblocked in OnTrade() after the order number has been found and some analysis of its fate has been done.

We have two questions:

1. What is the order ticket to be checked in OnTrade? Which statuses are final in its lifetime?

2. I know that the queue of Tick events (OnTick) can "drop". I.e. if another Tick event arrives and OnTick function (from previous Tick) hasn't finished its work yet, current event will be "dropped", i.e. it won't be processed. Is there a similar approach with Trade events (OnTrade)? I.e., is it possible that, for example, in the main loop I put a trade ban and the OnTrade event on the just sent order "drops", because at the moment of its arrival I will still be processing something in the same tick as sending the corresponding trade order?

 
voix_kas: I.e., is there a probability that, for example, I place a trade ban in the main loop and the OnTrade event on the order just sent "drops out", because at the moment of its arrival I will still be processing something in the same tick as sending the corresponding trade order?

Haven't dealt with this topic, but here's what the Handbook says:

1) Transactions queue length is 1024 items. If OnTradeTransaction() takes too long to process another transaction, old transactions in the queue may be superseded by newer ones;

2) OnTrade is called after appropriate OnTradeTransaction calls.

 
Yedelkin:

Haven't dealt with this topic, but here's what the Handbook says:

1) Transactions queue length is 1024 items. If OnTradeTransaction() takes too long to process another transaction, old transactions in the queue may be superseded by newer ones;

2) OnTrade is called after appropriate OnTradeTransaction calls.

Generally understood. Aspapaklass already pointed out and said in the articlehttps://www.mql5.com/ru/articles/232:

There is only one guaranteed way to find out exactly what has changed on a trade account. That way is to remember the state of the trade and trading history and compare the new state with the saved one.

One more service block in the Expert Advisor. :(

Actually, the question is this. Can we reduce the code size without analyzing all variables (orders/trades/positions), and only focus on the order number obtained from the OrderSend result? Or this number may be non-unique/not reflected in the history?

 
voix_kas: Can we reduce the code size without analyzing all variables (orders/trades/positions), and focus only on the order whose number is obtained from the result of the OrderSend? Or this number may be non-unique/not reflected in the history?

Of course. If a trade request resulted in the receipt of an order ticket, then this ticket is unique, and the entire fate of the order can be traced by it.

Here you can see how the order ticket is used in the history: MQL5 Reference / Trading Functions / HistoryOrderGetInteger

 
Yedelkin:
Of course. If a trade request has resulted in an order ticket, then that ticket is unique and can be used to track the entire fate of the order.
Just for info. In case the order was not accepted by the server for execution, e.g., a requote, is the MqlTradeResult.order variable assigned a default value (e.g., "0")?
 
voix_kas: In case an order was not accepted by the server for execution, e.g., a requote, is the MqlTradeResult variable Result.order assigned some default value (e.g., "0")?
A variable of MqlTradeResult type is usually zeroed before being used. So, the Result.order field contains a zero value. I've never seen this field take a different value after unsuccessful sending of a trade request.
Документация по MQL5: Торговые функции / OrderSend
Документация по MQL5: Торговые функции / OrderSend
  • www.mql5.com
Торговые функции / OrderSend - Документация по MQL5
 
Yedelkin:
A variable of MqlTradeResult type is usually zeroed before it is used. So Result.order field contains zero value. I've never seen this field take a different value after unsuccessful sending of trade request.
If you don't mind, I'd like to go deeper into the question of interpreting return codes. 24 out of 30 declared responses (let's hope we won't encounter undeclared ones) clearly indicate order placement failure. The other 6: 1. TRADE_RETCODE_PLACED Suppose we do not place pending orders. Is this response possible in market trading (SYMBOL_TRADE_EXECUTION_MARKET)? 2. TRADE_RETCODE_DONE Nothing further can be checked. Everything went exactly as described by the Expert Advisor. 3. TRADE_RETCODE_DONE_PARTIAL I assume that this answer is similar to TRADE_RETCODE_DONE given the ORDER_FILLING_IOC mode, if trading without pending orders. 4. TRADE_RETCODE_ORDER_CHANGED Does this mean unambiguous rejection of our trade order? 5. TRADE_RETCODE_LOCKED I think this is the worst case. What should we do in this case? I suggest that the order number is not available yet. The trade flow is busy. We cannot trade and it is not clear how we can know that the trade flow is unblocked. 6. TRADE_RETCODE_FROZEN Does this mean unambiguous rejection of our trade order? Please comment on each item.
 

voix_kas: Если не возражаете, хотелось бы углубиться в вопрос интерпритации кодов возврата. Из 30 задекларированных вариантов ответа (будем надеятся, что с недекларированными мы не столкнёмся) 24 - указывают на явный отказ в размещении ордера. Остальные 6:  

1. TRADE_RETCODE_PLACED Assume no pending orders. Is this answer possible during market trading (SYMBOL_TRADE_EXECUTION_MARKET)?

TRADE_RETCODE_DONE Nothing further can be checked. Everything went exactly as the Expert Advisor requested.

3. TRADE_RETCODE_DONE_PARTIAL I assume that this answer is the same as TRADE_RETCODE_DONE given the ORDER_FILLING_IOC mode.

4. TRADE_RETCODE_ORDER_CHANGED Does this mean unambiguous rejection of our trade order?

5. TRADE_RETCODE_LOCKED I think this is the worst case. What should we do in this case? I suggest that the order number is not available yet. The trade flow is busy. We cannot trade, and it is not clear how we should know whether the trade flow is unblocked.

6. TRADE_RETCODE_FROZEN Does this mean unambiguous rejection of our trade order?

Please comment on each item.

Unfortunately, my knowledge is not enough for a full comment on each point. Well, if something happens, my colleagues will correct it.

1. The forum once mentioned a situation where a trading account can be opened with a sub-broker. In this case the sub-broker can send the trade request for processing further (to the broker) and send TRADE_RETCODE_PLACED to the client terminal. Whether the broker will eventually process such a trade request is unknown.

2. Yes, I think so too. The only thing we should remember is that information about this order will be received in the terminal database asynchronously.

I think we are talking about partial execution of a trade request in ORDER_FILLING_IOC and ORDER_FILLING_RETURN modes.

4. https://www.mql5.com/ru/forum/1111/page124#comment_18407

5. I know absolutely nothing about this code. Technically, it turns out that the request was not processed due to some internal reasons of the broker. Whether it will be processed later is not clear. I myself equate this code to the rejection of a trade request.

6. https://www.mql5.com/ru/forum/1111/page123#comment_18372

..And in general - try a forum keyword search. You can find a lot more information :)

 
Yedelkin:

Unfortunately, I don't have enough knowledge to comment fully on each of the points. Well, if anything, colleagues will correct it.

1. The forum once mentioned a situation in which a trading account can be opened with a sub-broker. In this case the sub-broker can send the trade request for processing further (to the broker) and send TRADE_RETCODE_PLACED to the client terminal. Whether the broker will eventually process such a trade request is unknown.

2. Yes, I think so too. The only thing we should remember is that information about this order will be received in the terminal database asynchronously.

I think we are talking about partial execution of a trade request in ORDER_FILLING_IOC and ORDER_FILLING_RETURN modes.

4. https://www.mql5.com/ru/forum/1111/page124#comment_18407

5. I know absolutely nothing about this code. Technically, it turns out that the request was not processed due to some internal reasons of the broker. Whether it will be processed later is not clear. I myself equate this code to the rejection of a trade request.

6. https://www.mql5.com/ru/forum/1111/page123#comment_18372

..And in general - try a forum keyword search. You can find much more information :).

Here we have the following: 26 out of 30 codes (including TRADE_RETCODE_ORDER_CHANGED and TRADE_RETCODE_FROZEN) represent explicit rejection of request (does not generate an order).

TRADE_RETCODE_DONE and TRADE_RETCODE_DONE_PARTIAL - guaranteed created order.

How to correctly execute TRADE_RETCODE_PLACED (not pending) and TRADE_RETCODE_LOCKED is a question. Comments from MQ on these two codes would be appreciated.

 
That's cool, Happy New Year #2015 everyone, but I wonder how it ended. It's been two years of silence....
123456789
New comment
Reason: