Discussione sull’articolo "Manuale MQL5: Elaborazione dell'evento TradeTransaction"

Nuovo commento
 

Il nuovo articolo Manuale MQL5: Elaborazione dell'evento TradeTransaction è stato pubblicato:

Questo articolo considera le capacità del linguaggio MQL5 dal punto di vista della programmazione event-driven. Il più grande vantaggio di questo approccio è che il programma può ricevere informazioni sull'attuazione graduale di un'operazione di trading. L'articolo contiene anche un esempio di ricezione ed elaborazione di informazioni sull'operazione di trading in corso utilizzando il gestore dell'evento TradeTransaction. A mio parere, un tale approccio può essere utilizzato per copiare le offerte da un terminale all'altro.

Prima di ciò, dovremo creare un modello dell'Expert che conterrà il gestore dell'evento TradeTransaction. Ho chiamato la mia versione del modello TradeProcessor.mq5. Ho aggiunto una funzionalità che abilita la visualizzazione delle informazioni sui valori dei campi della struttura nel log. Questi valori sono i parametri dell'evento - gestore. L'analisi di questi record richiederà molto tempo, ma alla fine ripagherà presentando il quadro completo degli eventi.

Dobbiamo avviare l'Expert in modalità debug su uno qualsiasi dei grafici nel terminale MetaTrader 5.

Apri una posizione manualmente e dai un'occhiata al codice. La prima chiamata dell'handler sarà così (Fig. 1).

Fig. 1. Il campo tipo è uguale a TRADE_TRANSACTION_REQUEST

Fig.1. Il campo del tipo è uguale a TRADE_TRANSACTION_REQUEST

Autore: Denis Kirichenko

 

In base alla mia esperienza, posso dire che la vera necessità di utilizzare TradeTransaction si presenta quando si programma in modalità asincrona. È un peccato che l'articolo non dica una parola su questa modalità.

s.s. Pensavo anche che "Quali ricette MQL". - fosse un titolo tipico degli articoli di Anatoly. Ma ora si scopre che non è così(

 

C-4, grazie per la tua opinione.

C-4:

In base alla mia esperienza posso dire che la vera necessità di utilizzare TradeTransaction si presenta quando si programma in modalità asincrona. È un peccato che l'articolo non parli di questa modalità...

Esistono esigenze e requisiti diversi che possono giustificare l'uso del gestore di TradeTransaction. Si tratta di un argomento interessante, spero che anche i colleghi più esperti commentino la questione...

s.s. Anch'io pensavo che "ricette MQL". - fosse il nome degli articoli di Anatoly. Ora si scopre che non è così(

Sì, ammetto che Anatoly è l'inventore di questa serie di articoli. Mi è piaciuto, quindi mi sono modestamente unito al ciclo :-))))

Spero che ad Anatoly non dispiaccia....

 
Non ho ancora avuto il tempo di trattare la questione dell'esecuzione parziale degli ordini(ORDER_STATE_PARTIAL) in questo articolo. Una domanda per voi: quante volte verrà chiamato il gestore di TradeTransaction?
 
denkir:
Non ho ancora avuto il tempo di trattare la questione dell'esecuzione parziale degli ordini(ORDER_STATE_PARTIAL) in questo articolo. Una domanda per voi: quante volte verrà chiamato il gestore della TradeTransaction?

Non lo so. A rigor di logica, il gestore dovrebbe essere attivato tante volte quanto in un'esecuzione completa. Perché l'esecuzione dell'ordine non è un evento discreto e MT non sa se l'ordine verrà eseguito parzialmente o completamente.

Purtroppo la consegna degli eventi non è garantita e gli eventi stessi funzionano solo in tempo reale, il che ne limita l'applicazione. Tuttavia, sono estremamente utili per i sistemi basati sul tracciamento degli stati, come i sistemi asincroni o i copiatori di scambi. Grazie agli eventi è possibile costruire un algoritmo senza looping e freni aggiuntivi associati all'attesa dell'evento OnTimer.

 
denkir:

...

Spero che ad Anatoly non dispiaccia...

No, certo che non gli dispiace. ) Soprattutto perché...

C-4:

...

s.s. Pensavo anche che "ricette MQL". - fosse un marchio degli articoli di Anatoly. Ora si scopre che non lo è(

...L'etichetta "MQL5 Recipes" è stata suggerita dalla redazione di MQ, quindi può essere utilizzata da chiunque. L'importante è avere sempre più articoli diversi.

 
Il manuale di riferimento afferma chiaramente che la coerenza NON è garantita! Se si osservano i dati storici, la coerenza è ben diversa.
 
Grazie per questo articolo. È molto utile.
 
come faccio a far funzionare il sistema?
 
Un testo eccellente! Ho imparato molto qui, complimenti
 
VikMorroHun #:
Grazie per questo articolo. È molto utile.

Ciao,

La mia situazione sembra essere abbastanza semplice: Inserisco un ordine pendente (Sell_Stop) e voglio essere in grado di reagire nel caso in cui a) l'ordine pendente venga eseguito e infine b) la posizione aperta sia stata chiusa da uno stop loss o da un profit target.

Ho capito bene che:

  1. quando l'ordine pendente è stato eseguito posso ottenere il numero magico solo richiedendolo dalla lista delle posizioni nonostante il parametro "request" di OnTradeTransaction() possieda il campo "magic" come:
             if(!PositionSelectByTicket(trans.position)) {Print(__LINE__," PositionSelectByTicket FAILED ",err());}
         else {      
            OpnPos[sz].mag  = PositionGetInteger(POSITION_MAGIC);
         }  

  2. i vari tipi di transazione in modo da non poter sapere se la posizione di vendita è stata aperta o chiusa:
    void OnTradeTransaction(const MqlTradeTransaction& trans,
                        const MqlTradeRequest& request,
                        const MqlTradeResult& result)
  {
//---

//--- 
   static int counter=0;   // contatore delle chiamate a OnTradeTransaction() 
   static uint lasttime=0; // ora dell'ultima chiamata di OnTradeTransaction() 
//--- 
   uint time=GetTickCount(); 
//--- se l'ultima transazione è stata eseguita più di 1 secondo fa, 
   if(time-lasttime>1000) 
     { 
      counter=0; // allora si tratta di una nuova operazione di compravendita e il contatore può essere azzerato 
      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)
         );
    Questa stampa produce il caso di apertura di una posizione alle 01:00:40 e di chiusura di questa posizione alle 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
    Le chiamate sembrano più o meno le stesse - come mai? All'1:00 è stata aperta una vendita - perché ci sono 12 ..TYPE_BUY e solo 2 TYPE_SELL?
    Perché e qual è il significato di request.type = ORDER_TYPE_BUY nel caso in cui uno stop di vendita venga attivato e diventi una vendita (posizione)? Da dove viene il _BUY?
Conoscete un modo elegante per determinare che una posizione è stata chiusa da uno stop loss o da un obiettivo di profitto con i mezzi (parametri) di OnTradeTransaction() senza sapere se era una posizione di vendita o di acquisto?
12
Nuovo commento