OnTradeTransaction processing - page 2

New comment
 
fxsaber:

Can we have >=2 take and stop orders at the same time?

Yes, that's right, we made an initial entry and set a TP and a stop order. Then some time later we may have added more entries and set more TPs and stops.

 

In case of a lost event, I remember the orders placed, the ticket of the last accounted trade, the time of the last record (change) of the state, and periodically, as well as during the initial, I synchronize the list of orders and check for unaccounted trades.

Occurrence of events at random is the norm, absence of (temporary) orders in both orders and history is not uncommon and may occur both before and after a deal has occurred.

A position at netting receives a ticket of the first order and at further trades(changes) saves it until it is closed (i.e., becomes 0.0).

Well, depending on the volume of the order, it may generate several trades.
 
Илья Ребенок:


Share your experiences and ideas please.

You're not doing it right from the start.

Why magicians and all sorts of checks?

The ticket of an order is a unique identifier.

If you send a synchronous order, you will receive a ticket as a result of the function.

If you send an asynchronous order, we get the ticket in OnTradeTransaction.

Added

And herehttps://www.mql5.com/ru/forum/67298/page2#comment_2089220

is a good function to check the order

ФОРТС: В помощь начинающим
ФОРТС: В помощь начинающим
  • 2015.11.25
  • www.mql5.com
Установка отложенного ордера командой OrderSend().
 
Илья Ребенок:

Yes, that's right, we made an initial entry and set a TP and a stop order. Then, after some time, we could make a top-up and place another TP and stop orders.

Limit orders which require TP/SL could be executed partially. At the same time, TP in the form of Limit orders will be executed in the same way. For example, TP is executed by one third of the volume - the SL should be decreased by the same amount.

All in all, quite unpleasant logic for catching all the tricks.


The task should be implemented in OnTrade. It should not be difficult to implement.

 
prostotrader:

You're doing it all wrong from the start.

Why magicians and all sorts of checks?

The ticket of an order is a unique identifier.

If you are sending a synchronous order, then the ticket is received as a result of the function.

If you send an asynchronous order, we get the ticket in OnTradeTransaction.

Added

And herehttps://www.mql5.com/ru/forum/67298/page2#comment_2089220

is a good function to check the order

Thank you, I will read it.
JRandomTrader:

In case of loss of an event, I remember placed orders, ticket of last accounted transaction, time of last entry (change) of state, and periodically, as well as when it happens, I synchronize the list of orders and check for unrecorded deals.

Occurrence of events at random is the norm, absence of (temporary) order in both orders and history is not uncommon and may occur both before and after a deal has occurred.

The position at netting gets a ticket of the first order and on further trades(changes) it saves it until it closes (i.e., becomes 0.0).

Well, depending on the volume of the order, it may spawn multiple trades.

One of the goals of the robot was to get rid of the local dependency. In other words, it only receives data from the market without being bound to the variables of the terminal or a PC. This means that in case of an urgent need I have to switch to another PC and the robot will pick up everything.

Now I have seen another interesting bug. I received 2 identical TRADE_TRANSACTION_DEAL_ADD transactions. I'm sorry, what the hell is this?) The robot ended up putting 2 stops on 1 transaction.

2019.02.08 10:55:29 [INFO]: ( PChBreak_RTS-3.19_22 ) TRADE_TRANSACTION_DEAL_ADD
TRADE_TRANSACTION_DEAL_ADD
Symbol: RTS-3.19
Deal ticket: 12674810
Deal type: DEAL_TYPE_BUY
Order ticket: 82646001
Order type: ORDER_TYPE_BUY
Order state: ORDER_STATE_STARTED
Order time type: ORDER_TIME_GTC
Order expiration: 1970.01.01 00:00
Price: 119700
Price trigger: 0
Stop Loss: 0
Take Profit: 0
Volume: 1
Position: 82646001
Position by: 0

2019.02.08 10:55:32 [INFO]: ( PChBreak_RTS-3.19_22 ) TRADE_TRANSACTION_DEAL_ADD
TRADE_TRANSACTION_DEAL_ADD
Symbol: RTS-3.19
Deal ticket: 12674810
Deal type: DEAL_TYPE_BUY
Order ticket: 82646001
Order type: ORDER_TYPE_BUY
Order state: ORDER_STATE_STARTED
Order time type: ORDER_TIME_GTC
Order expiration: 1970.01.01 00:00
Price: 119700
Price trigger: 0
Stop Loss: 0
Take Profit: 0
Volume: 1
Position: 82646001
Position by: 0

 

Transaction events(TRADE_TRANSACTION_DEAL_ADD) come several times regularly.

Fortunately, only the most recent one repeats (at least I didn't catch older ones).

To filter it is enough to check if the transaction ticket is the same as the previous one.

 
Ilya Baranov:

Transaction events(TRADE_TRANSACTION_DEAL_ADD) come several times regularly.

Fortunately, only the most recent one repeats (at least I didn't catch older ones).

To filter it, it's enough to check if the transaction ticket is the same as the previous one.

Not multiple times, but by the number of EAs currently working in the terminal.

Therefore, each EA should process its own order

case TRADE_TRANSACTION_DEAL_ADD:
      if((BuyOrder.ticket > 0) && (trans.order == BuyOrder.ticket))  // Buy order
      {
        //Сделка этого советника
      }
break;
 
prostotrader:

Not multiple times, but by the number of EAs currently working in the terminal.

Therefore, each EA has to process its own order

Your code protects against the fact that it was a trade of this EA.

I and TS are speaking about cases when OnTradeTransaction with theTRADE_TRANSACTION_DEAL_ADD typeis called several times for one trade, i.e. the other fields of MqlTradeTransaction contain exactly the same data.

It means that in your case the processing code can be executed several times.

Perhaps, this is not the case with all brokers. But it happens regularly at all stockbrokers I worked with.

 
Ilya Baranov:

Your code protects against the fact that it was this EA's trade.

I and TS are talking about cases when OnTradeTransaction withTRADE_TRANSACTION_DEAL_ADD typeis called several times for one trade, i.e. other fields of MqlTradeTransaction have exactly the same data.

It means that in your case the processing code can be executed several times.

Perhaps, this is not the case with all brokers. But it happens regularly with all brokers I worked with.

I trade at Otkryvashka on real and test it on demo but I don't have multiple triggers.

Post your piece of code forTRADE_TRANSACTION_DEAL_ADD

 
Ilya Baranov:

Transaction events(TRADE_TRANSACTION_DEAL_ADD) come several times regularly.

Fortunately, only the most recent one repeats (at least I didn't catch older ones).

To filter, it's enough to check if the transaction ticket is the same as the previous one.

Yes, thanks! Just did that after what I saw.

As for the original problem, put a slip to have time to pump the transaction to delete the order and add it to history. Observed.

The imperfection of the platform in this respect is very sad. Things that should be bundled together make separate ones.

prostotrader:

Not several times but by the number of EAs working in the terminal at the moment.

That is why each EA has to process its own order

In this case, I still need to store the ticket of the order from the requester somewhere to compare it with the ticket from the trade. And I just want to get rid of all storage in local variables and get info solely from market/terminal to level out local infrastructure risks.
12345678910
New comment