OnTradeTransaction processing - page 6

 

Good afternoon.

No one is intimidated by anyone.

prostotrader:

You don't have switch(trans.type)

Well, of course the given case is in switch(trans.type). Since there was another case I didn't want to show all code so as not to overload it with unnecessary information.

fxsaber , thank you for the example!

Alexey, it is exactly the same. I'm using 2 different robots to trade on the same symbol in netting mode. Those 2 posts you quoted complement each other.

It's interesting to solve the problem starting from the primary change trigger - onTradeTransaction.

Total current problems encountered:

1. deal_add triggers, but no pose. No thoughts so far.

2. deal_add is triggered, but the order is in the third dimension. Put a slip, last couple of days seems to help. The order manages to get to history in 1 second. I do not have highfrequency trading robots and do not use market orders, therefore this solution would be appropriate.

3. deal_add is triggered 2 times, i.e. one and the same deal_add is triggered 2 times. This can be solved by checking the ticket of a previous deal and comparing it to the current one.

There is still point 1. Explanations for it.

Yesterday I set sell_limit, it worked, deal_add came, but position did not appear and we opened a stop order for nothing. I started to look at the transaction description and saw that the deal type is DEAL_TYPE_SELL but the order type is ORDER_TYPE_BUY. At the same time, the order ticket is ours. It didn't seem to be quite logical. I decided to check that the order type and trade type should be the same in OnTradeTransaction, that the order type and trade type should be the same.

I have put the robot on the demo and got another similar transaction but this time the position has changed. But because of our check the stop order has not been executed. What is going on?

2019.02.08 16:05:14 [INFO]: ( FrTrend_2_Si-3.19_33) TRADE_TRANSACTION_DEAL_ADD
TRADE_TRANSACTION_DEAL_ADD
Symbol: Si-3.19
Deal ticket: 12677775
Deal type: DEAL_TYPE_SELL
Order ticket: 82675535
Order type: ORDER_TYPE_BUY
Order state: ORDER_STATE_STARTED
Order time type: ORDER_TIME_GTC
Order expiration: 1970.01.01 00:00
Price: 66287
Price trigger: 0
Stop Loss: 0
Take Profit: 0
Volume: 1
Position: 82675534
Position by: 0

I will tell you right away, this is what is coming into the terminal. Without my making it up.

 
Илья Ребенок:

Yesterday I placed sell_limit, it triggered, deal_add came, but no position appeared and we opened stop orders for nothing. I have started to look at the transaction description and have seen that the deal type is DEAL_TYPE_SELL and the order type is ORDER_TYPE_BUY. At the same time, the order ticket is ours. It didn't seem to be quite logical. I have decided to check that order type and transaction type should coincide in OnTradeTransaction on deal_add transaction.

But here it's worth re-reading the"Trade transaction structure" help - in terms of what fields are filled in for deal_add type.

And to take the order properties not from the transaction (where they are not filled, but zeros also correspond to some values in enum-type), but from the order itself, if it is available at the moment (and not during transition from orders to history).

 

This makes it easier to analyse how things are going.


You can add that along with transactions the status of positions, current orders and trading history can also be logged. Then the whole picture will be available.

 
JRandomTrader:

This is where the"Structure of a trade transaction" help is worth re-reading - in terms of what fields are filled in for the deal_add type.

And to take the order properties not from the transaction (where they are not filled in, but zeros also correspond to some values in the enum-type), but from the order itself, if it is currently available (and not in the process of transition from orders to history).

I agree, I was aware of that, but didn't pay attention. Thanks for reminding me.

However, the problem with a position not appearing in one case and appearing in another remains and is unclear.

 

Илья Ребенок:

However, the problem with the position not appearing in one case and appearing in the other remains and is unclear.

The position was ticketed in the deal_add transaction, but the position didn't exist before and it didn't show up? This has to be sorted out.

 
JRandomTrader:

The position was ticketed in the deal_add transaction, but the position was not there before and it did not show up? This needs to be sorted out.

the position was not there before

 
Илья Ребенок:

the position was not there before

Was there a position ticket in the transaction?

 
JRandomTrader:

Was there a position ticket in the transaction?

In the post above I must have made a bit of a misunderstanding. There was a position, then it was closed by stop orders. That is, the number of positions became 0. Then a trade was triggered, but the position did not appear.

I think this is what you mean. The transaction contained information about the position's ticket, but this ticket = ticket of the previous order. As it should be in netting mode, if I understand correctly.

Position: 82675534
 
Илья Ребенок:

In the post above I must have made a bit of a misunderstanding. There was a position, then it was closed by stop orders. That is, the number of positions became 0. Then a trade was triggered, but the position did not appear.

I think this is what you mean. The transaction contained information about the position's ticket, but this ticket = ticket of the previous order. As in general it should be in netting mode, if I understand correctly.

If the position on the symbol (cumulative, all robots and manual trades together) became 0.0, then the next transaction will open (DEAL_ENTRY_IN) a new position, with a new ticket (==ticket of order).

Actually, it seems to me that when netting, there is no need to look at the position at all - each robot has to account for "its" - as the results of trades on its orders.

 

Presence of positions and DEAL_ENTRY flags should not be involved in the logic in any way.

We only need to look at the magick and comment of new trades and current orders as identifiers of own/foreign.


The working code showed. It is exactly the same.

Trying to solve the problem via OnTradeTransaction is a poor idea of the number of pitfalls. Which in a particular task can sometimes still be bypassed. But if you change the task just a bit, the entire logic is broken during OnTradeTransaction-implementation.

The developers have created an event-driven trade model but they have not provided a single working example. Because it's a complete asshole what the code pours into and how much it depends on each example.

Therefore, I would recommend looking at synchronous trading operations and OnTrade function. Everything is much easier there and the logic is very flexible for changes. Moreover, it's more reliable.


The transition to Async+Transactions is comparable with the transition from the high-level language to the assembler. I.e. it should be done at the very last stage of TS creation, when it is FULLY researched, ready for REAL and the last thing is to speed up trading operations WITHOUT changing trading logic.