Discussion of article "MQL5 Cookbook: Processing of the TradeTransaction Event"

New comment
 

New article MQL5 Cookbook: Processing of the TradeTransaction Event has been published:

In this article I would like to introduce one of the ways to control trade events using the means of MQL5. I must mention that a few articles have already been dedicated to this topic. "Processing of trade events in Expert Advisor using the OnTrade() function" is one of them. I am not going to repeat other authors and will use another handler - OnTradeTransaction().

I would like to draw the readers' attention to the following point. The current version of the MQL5 language formally counts 14 event handlers of the Client Terminal. In addition, a programmer has a possibility to create custom events with EventChartCustom() and process them with OnChartEvent(). However, the term 'Event-driven programming' (EDP) is not mentioned in Documentation at all. It is strange, given the fact, that any program in MQL5 is created based on the EDP principles. For instance, the user is offered to make a choice at the step 'Events handler for the Expert' in a template of any Expert Advisor.

It is obvious that the mechanism of the Event-driven Programming is used in MQL5 one way or another. The language may contain program blocks consisting of two parts: selecting and processing of an event. Moreover, if we are talking about events of the Client Terminal, a programmer has control only over the second part, i.e. the event handler. To be fair, there are exceptions for some events. Timer and custom event are among them. Control of these events is left entirely for the programmer.

Fig.6. The first scheme of the transaction process

Fig.6. The first scheme of the transaction process

Author: Dennis Kirichenko

 

From my experience I can say that the real need to use TradeTransaction arises when programming in asynchronous mode. It is a pity that the article does not say a word about this mode.

s.s. I also thought "What MQL recipes". - was a trademark title of Anatoly's articles. But now it turns out that it is not so(

 

C-4, thank you for your opinion.

C-4:

From my experience I can say that the real need to use TradeTransaction arises when programming in asynchronous mode. It's a pity that the article doesn't say a word about this mode ...

There are different needs and requirements that can be the reason to use TradeTransaction handler. This is an interesting topic, I hope that experienced colleagues will also comment on this issue...

s.s. I also thought "MQL recipes". - was the brand name of Anatoly's articles. Now it turns out that it is not(

Yes, I admit that Anatoly is the inventor of this series of articles. I liked it, so I modestly joined the cycle :-))))

I hope Anatoly doesn't mind....

 
I have not yet had time to cover the issue of partial order execution(ORDER_STATE_PARTIAL) in this article. Question for you, how many times will the TradeTransaction handler be called?
 
denkir:
I have not yet had time to cover the issue of partial order execution(ORDER_STATE_PARTIAL) in this article. Question for you, how many times will the TradeTransaction handler be called?

I don't know. Logically, the handler should be triggered as many times as in a full execution. Because order execution is not a discrete event, and MT does not know whether the order will be executed partially or completely.

s.s. Unfortunately, the delivery of events is not guaranteed, and the events themselves work only in real time, which makes their application limited. But they are extremely useful for systems based on state tracking, such as asynchronous systems or trade copiers. Thanks to events it is possible to build an algorithm without looping and additional brakes associated with waiting for OnTimer event.

 
denkir:

...

I hope Anatoly doesn't mind...

No, of course he doesn't mind. ) Especially since...

C-4:

...

s.s. I also thought "MQL recipes". - was a brand name of Anatoly's articles. Now it turns out that it is not(

...The label "MQL5 Recipes" was suggested by the MQ editorial staff, so it can be used by anyone. The main thing is to have more and different articles.

 
The reference manual clearly states that consistency is NOT guaranteed! If you look at historical data, the consistency is quite different.
 
Thanks for this article. It is very useful.
 
how do i get the system to work ?
 
Excellent text! I learnt a lot here, congratulations
 
VikMorroHun #:
Thanks for this article. It is very useful.

Hi,

My situation seems to be quite simple: I place a pending order (Sell_Stop) and I want to be able to react in case a) the pending order is filled and finally b) the open position was closed by either stop loss or profit target.

Do I understand it correctly that:

  1. when the pending order was filled I can get the magic number onlyby requesting it from the list of positions despite the parameter "request" of OnTradeTransaction() owns the field "magic" like:
             if(!PositionSelectByTicket(trans.position)) {Print(__LINE__," PositionSelectByTicket FAILED ",err());}
         else {      
            OpnPos[sz].mag  = PositionGetInteger(POSITION_MAGIC);
         }  

  2. the various transaction types in a way that I cannot know whether the sell position was opened or closed:
    void OnTradeTransaction(const MqlTradeTransaction& trans,
                        const MqlTradeRequest& request,
                        const MqlTradeResult& result)
  {
//---

//--- 
   static int counter=0;   // counter of OnTradeTransaction() calls 
   static uint lasttime=0; // time of the OnTradeTransaction() last call 
//--- 
   uint time=GetTickCount(); 
//--- if the last transaction was performed more than 1 second ago, 
   if(time-lasttime>1000) 
     { 
      counter=0; // then this is a new trade operation, an the counter can be reset 
      if(IS_DEBUG_MODE) 
         Print(__LINE__," "," New trade operation dTime",time-lasttime); 
     } 
   Print(__LINE__," ",counter," ",DoubleToString((double(lasttime=time)/1000.0,2)
            ," Tr.Type: ",EnumToString(trans.type)," DL.Type: ",EnumToString(trans.deal_type)
            ," RQ.Type: ",EnumToString(request.type)," RQ.Fill: ",EnumToString(request.type_filling)
         );
    This Print produces in case of opening a position at 01:00:40 and closing this position at 10:04:40:
    01:00:40   322 0 81952.76 Tr.Type: TRADE_TRANSACTION_DEAL_ADD DL.Type: DEAL_TYPE_SELL RQ.Type: ORDER_TYPE_BUY RQ.Fill: ORDER_FILLING_FOK // open sell position
10:04:40   322 0 81970.73 Tr.Type: TRADE_TRANSACTION_DEAL_ADD DL.Type: DEAL_TYPE_BUY  RQ.Type: ORDER_TYPE_BUY RQ.Fill: ORDER_FILLING_FOK // close sell position

01:00:40   322 0 81955.30 Tr.Type: TRADE_TRANSACTION_ORDER_DELETE DL.Type: DEAL_TYPE_BUY RQ.Type: ORDER_TYPE_BUY RQ.Fill: ORDER_FILLING_FOK // open sell position
10:04:40   322 0 81980.91 Tr.Type: TRADE_TRANSACTION_ORDER_DELETE DL.Type: DEAL_TYPE_BUY RQ.Type: ORDER_TYPE_BUY RQ.Fill: ORDER_FILLING_FOK // close sell position

01:00:40   322 0 81965.14 Tr.Type: TRADE_TRANSACTION_HISTORY_ADD DL.Type: DEAL_TYPE_BUY RQ.Type: ORDER_TYPE_BUY RQ.Fill: ORDER_FILLING_FOK // open sell position
10:04:40   322 0 81982.69 Tr.Type: TRADE_TRANSACTION_HISTORY_ADD DL.Type: DEAL_TYPE_BUY RQ.Type: ORDER_TYPE_BUY DL.Type: ORDER_FILLING_FOK // close sell position

01:00:59   322 0 81968.50 Tr.Type: TRADE_TRANSACTION_REQUEST     DL.Type: DEAL_TYPE_BUY RQ.Type: ORDER_TYPE_SELL RQ.Fill: ORDER_FILLING_FOK // open sell position
    The calls look pretty much the same - how that? At 1:00 a sell was opened - why are there  12  ..TYPE_BUY and only 2 TYPE_SELL??
    Why and what is the meaning of request.type = ORDER_TYPE_BUY in case a sell stop gets triggered and becomes a sell (position)?? From where is the _BUY?
Do you know an elegant way to determine that a position has been closed by stop loss or profit target with the means (parameters) of OnTradeTransaction() without knowing whether it was a sell or a buy position is closed?
12
New comment