Features of the mql5 language, subtleties and tricks

New comment
Artyom Trishkin  
This thread will discuss undocumented methods of working with the mql5 language, examples of solving certain problems. It would be desirable, that this branch on the maintenance was closer to FAQ, than to discussion. I suggest that all experienced programmers share their solutions and programming techniques. The coverage of features not described in the help is especially welcome.
fxsaber  
fxsaber:

whena position is successfullyopened by a market order, a null Result.deal is obtained every time?

From the BOD
The filling of the Result deal ticket is not guaranteed. Whether it is filled or not depends on the instrument's execution mode and the settings of a particular server.
Who laid down on a non-zero Result.deal - take action.
Alexey Volchanskiy  
fxsaber:
After executing OrderSend, addressing the corresponding order, position, or trade is not always successful. There are situations when it is necessary to wait for several tens of milliseconds until historical or current trade information becomes correct.
the same is also found in MT4, it depends on the specific server
fxsaber  
It is not always possible to know the price of the order that generated the trade
fxsaber  
It is not always possible to find out the SL/TP levels of a closed position.

Forum on trading, automated trading systems and trading strategies testing

TakeProfit (and StopLoss) of a closed position

fxsaber, 2016.07.17 20:19

Before the introduction of hedge TakeProfit open positions were not stored on the exchange in the form of limit orders, but on the MT5 trading server. And at the moment of acceptance, they were sent to the exchange not as limit orders at the declared price, but as market orders at the declared price.

This feature is very well visible in the tester, when the TP is triggered: the corresponding market order (rather than limit) appears. Since takeprofit is a non-existent exchange type of orders (there are only market and limit orders), this state of affairs was quite consistent with "marketability".

The situation did not change with the appearance of the hedge - takeprofit remains virtual. The situation is different in MT4: Over the years of MT4 bridges, it has become standard that MT4 takeprofit orders are limit orders.

It is because of this virtuality that certain features of MT5 are dragging on like a trail. Not only is takeprofit better not to be set in MT5, but if you want a limit analogous to it, there is no way through MQL5 to know the takeprofit and stoploss values after you close a position.

This is not indiscriminate accusation, but the result of hours of trying to find out (no HistorySelectByPosition and other stuff helps) how everything works. And I'm happy to apologize if I'm wrong. So as not to be unfounded, I bring an Expert Advisor for the tester (it's easier to understand) on the server RoboForexEU-MetaTrader 5, which opens a position and then puts SL and TP levels.

void OnTick()
{
  static bool Flag = true;

  if (Flag)
  {
    // Открываем SELL-позицию
    MqlTradeRequest Request = {0};

    Request.action = TRADE_ACTION_DEAL;

    Request.symbol = Symbol();
    Request.volume = 1;
    Request.price = SymbolInfoDouble(Symbol(), SYMBOL_BID);

    Request.type = ORDER_TYPE_SELL;

    MqlTradeResult Result;

    if (OrderSend(Request, Result))
    {
      // Устанавливаем SL и TP
      Request.position = Result.deal;

      Request.action = TRADE_ACTION_SLTP;

      Request.tp = Result.ask - 10 * _Point;
      Request.sl = Result.ask + 10 * _Point;

      if (OrderSend(Request, Result))
        Print("Сделка в тестере закроется либо по SL, TP, либо по окончании бэктеста")    ;

      Flag = false;
    }
  }
}

In this EA, SL and TP of the only closed position cannot be defined (in OnDeinit). Is it supposed to be like that?


From the quote it also follows that the TP of a position in MT5 is always a market order. You don't need a limit counterpart - see above.
Stop Loss/ Take Profit OnTradeTransaction Questions from Beginners MQL5
[Deleted]  

Forum on trading, automated trading systems and trading strategies testing

Bugs, bugs, questions

Slawa, 2017.02.14 13:46

Why? A single action is enough.

While the symbol is selected in the market review and the history on the symbol is held by the Expert Advisor, it is kept in a synchronized state. If the Expert Advisor keeps the history at least once every 2 minutes, then it will be accessed, for example, by copying one bar. If the history is synchronized, no time is spent on copying one bar - only a few clock cycles of the processor. Or, as it was just said here, to ask the number of bars, also a few clock cycles

Forum on trading, automated trading systems and testing trading strategies

Bugs, bugs, questions

Alexey Kozitsyn, 2017.02.14 13:47

Do the indicators include an interval of 2 minutes?

Yes, and by checking the fact of synchronization synchronization will also hold?

Forum on trading, automated trading systems and testing trading strategies

Bugs, bugs, questions

Slawa, 2017.02.14 13:50

This also applies to indicators. Create a 1-minute timer and ask the number of bars of all the timeseries you are interested in.

The synchronization is not held by checking the fact of synchronization.

Errors, bugs, questions Features of the mql4 Analogue to iBarShift
prostotrader  
fxsaber:
After OrderSend is executed, calling the corresponding order, position, or trade is not always successful. There are situations when it is necessary to wait several tens of milliseconds for historical or current trade information to become correct.

You don't have to wait a few milliseconds.

The message will come in OnTradeTransaction

see code

Files:
Test_sync_order.mq5  30 kb
fxsaber  
prostotrader:

You don't have to wait a few milliseconds.

The message will come in OnTradeTransaction

see code.

The scripts do not have it. It is stupid to use EA+ExpertRemove instead of script.

Moreover, OrderSend crashes by timeout if there is no response from the server for 180 seconds. This suggests that the OnTradeTransaction may accumulate tickets that are always pending. And the option of just one order_ticket for OnTradeTransaction, as in your script, is bad. The asynchronous sending is followed by the work with the lists of orders. That's why it's asynchronous - to work with batches. And if there is no work with batches, then asynchrony is never needed.

Question about the OnTradeTransaction OrderSend vs OrderSendAsynch How do I open
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223
New comment
Reason: