Libraries: TradeTransaction Class

New comment
 

TradeTransaction Class:

A base class to simplify coding of trade transactions in MQL5.

Author: amrali

TradeTransaction Class
TradeTransaction Class
  • www.mql5.com
When performing some definite actions on a trade account, its state changes. Such actions include: Sending a trade request from any MQL5 application in the client terminal using OrderSend and OrderSendAsync functions and its further execution;Sending a trade request via the terminal graphical interface and its further execution;activation of...
 
Automated-Trading:

TradeTransaction Class:

Author: amrali

Hello Amrali, your TradeTransaction class it's a truly illuminated work, because it has clarified the suitable situations to be intercepted, and to be able the programmer to follow appropriate functionalities "event based".

However I have noticed that OnTradeTransaction function intercepts ANY order-position-deal event generated across the platform. So I should disentangle myself between the "HistorySelect" and similar functions .... to be able to filter the events corresponding to the "magic number" of the specific strategy. I believe that the correct interpretation of the OnTradeTransaction, should filter the associated events specific to the strategy. have you found a unique way to filter events, based on the "magic number" of the strategy?

Have you solved this problem by any chance? Can you explain to us which is the right way to solve it?

thank you for your attention, with cordiality.

Sabino.

 

Hello Sabino,

you could modify the derived class to something like this to filter by magic numbers:

class CExtTransaction : public CTradeTransaction
  {
protected:
   //--- trade transactions
   virtual void      TradeTransactionOrderPlaced(ulong order)                      { if(OrderGetInteger(ORDER_MAGIC) == InpMagicNumber) {PrintFormat("Pending order is placed. (order %I64u)", order);} }
   virtual void      TradeTransactionOrderModified(ulong order)                    { if(OrderGetInteger(ORDER_MAGIC) == InpMagicNumber) {PrintFormat("Pending order is modified. (order %I64u)", order);} }

   virtual void      TradeTransactionPositionOpened(ulong position, ulong deal)    { if(HistoryDealGetInteger(deal, DEAL_MAGIC) == InpMagicNumber) {PrintFormat("Position is opened. (position %I64u, deal %I64u)", position, deal);} }
   virtual void      TradeTransactionPositionStopTake(ulong position, ulong deal)  { if(HistoryDealGetInteger(deal, DEAL_MAGIC) == InpMagicNumber) {PrintFormat("Position is closed on sl or tp. (position %I64u, deal %I64u)", position, deal);} }
   virtual void      TradeTransactionPositionClosed(ulong position, ulong deal)    { if(HistoryDealGetInteger(deal, DEAL_MAGIC) == InpMagicNumber) {PrintFormat("Position is closed. (position %I64u, deal %I64u)", position, deal);} }
   virtual void      TradeTransactionPositionCloseBy(ulong position, ulong deal)   { if(HistoryDealGetInteger(deal, DEAL_MAGIC) == InpMagicNumber) {PrintFormat("Position is closed by opposite position. (position %I64u, deal %I64u)", position, deal);} }
  };


 

 
amrali #:

Hello Sabino,

you could modify the derived class to something like this to filter by magic numbers: 

Massive thanks for this, Amr... your class appears to be truly excellent to simplify trade event handling, a huge bonus for productivity & reliability :-)

Quick question -- when OnTradeTransaction() is called, do we have a guarantee that MQL5 has already automatically selected the relevant order and/or deal in history from the terminal's cache, or it needs to be taken care of by the developer? In any case, I see that in your base CTradeTransaction class the functions OrderSelect() and HistoryDealSelect() are called anyway as the transaction is processed with the help of the macros defined at the top.

 
Thank you so much
 

Hi Amrali,

Been looking at your work and looking rather interesting.

Given that the Trade Transaction Queue is limited to 1024 events, do you think your implementation can handle stressed trading conditions - avoiding missed events?

I've been considering if it would make sense to use a shared memory queue and just pass the events from OnTradeTransaction to Shared Memory Queue, then have worker threads (Services) process the events - would this be overkill?

Thanks again for the great work.

Shep.

 

Good job Amrali, but I think there's a few bugs.

  • In the macro IS_TRANSACTION_ORDER_MODIFIED should be OrderSelect(request.order)
  • In the macros IS_TRANSACTION_ORDER_DELETED, IS_TRANSACTION_ORDER_EXPIRED and IS_TRANSACTION_ORDER_TRIGGERED the STOP LIMIT orders are omitted
I also think it would be better to use class methods instead of macros. If all the methods of the class were as static, then there is no need to define a global variable of that class. Using input for logging is also not the most appropriate in my opinion (you can add one parameter in the OnTradeTransaction method).
 
Petr Nosek #:

Good job Amrali, but I think there's a few bugs.

  • In the macro IS_TRANSACTION_ORDER_MODIFIED should be OrderSelect(request.order)
  • In the macros IS_TRANSACTION_ORDER_DELETED, IS_TRANSACTION_ORDER_EXPIRED and IS_TRANSACTION_ORDER_TRIGGERED the STOP LIMIT orders are omitted
I also think it would be better to use class methods instead of macros. If all the methods of the class were as static, then there is no need to define a global variable of that class. Using input for logging is also not the most appropriate in my opinion (you can add one parameter in the OnTradeTransaction method).

Thank you for spotting these bugs.

Fixed in the new release.

 

Update 5 March 2025 - version 1.10

Fixed issue with STOP LIMIT orders not being captured.

Added 'SetLogging' public method to control printing verbose information to 'Experts' logs.

New comment