Question about the OnTradeTransaction function - page 2

New comment
 
Mikalas:

Yes, it is possible not to use OnTradeTransaction, but then you would have to dig through the history, which would reduce the overall performance of the EA.

Every developer has a choice!

That's why I started digging in this direction...

Thanks for the clarification. I will keep digging. No one is rushing me. :))))

 
AlexeyVik:

That's why I started digging in that direction...

Thanks for the clarification. I'll keep digging. No one's rushing me. :))))

The thing is, the example I gave is just an insurance that the TradeTransaction event won't happen

In fact, I've had 6 months of EA's working daily on a real account with 2000 transactions a day,

I have NEVER had an "emergency" situation!

Good Luck!

 
C-4:
As if we understood everything and clap our hands for joy. Sorry, but your code is a mess.

Oh yeah, I completely forgot, Vasiliy!

The code is 100% working - throw the EA on the demo and see how it works

in normal mode, and then comment out the function OnTradeTransaction and you will

you will see how the "emergency" mode works.

 
AlexeyVik:

So, if you don't use asynchrony, there's no need for OnTradeTransaction handler, because the owls will wait for a response from the server?

Do not complicate things. There is no need to use asynchrony to trade on FORTS. For a start, see this article, chapter 3: "The basics of asynchronous operations". It's not much, it's very basic, but it's enough to start studying it. The code described there is 100% asynchronous, however, it does not prevent it from working in synchronous mode without getting all OnTradeTransaction and other events.

AlexeyVik:

But so far I haven't found the best way to determine if a stop order has been activated. For example, I set market Buy 0.1 and SellStop 0.3, but when it activates 0.3, it remains 0.2 and at what point should I follow it... So it turns out that we have to follow two orders at every tick. And I wanted to relieve the Owls and control only when the transaction happens. I wanted to not even control, but to check what happened and decide what to do. But I guess this is not the case... Perhaps it is better to return to the old, tried and tested methods...

The solution should be based on your task. In MetaTrader 5, you have only one active position at any given time, so it's up to you to keep an eye on it. There is no need to look into the order history. If you still need the order history, then you need to clarify your objective.

 
Mikalas:

Oh yeah, I completely forgot, Vasiliy!

The code is 100% working - throw the EA on the demo and see how it works

in normal mode, and then comment out the function OnTradeTransaction and you will

you will see how the "emergency" mode works.

I have looked at your code more closely. You are making it too complicated. There should not be any "emergency" mode. Regardless of whether you use synchronous or asynchronous type of trading, you must focus on the analysis of the trading environment. The analysis of events of OnTradeTransaction type is of an auxiliary character.

Mikalas:

Yes, you can choose not to use OnTradeTransaction but in this case you will have to look through the history, which will significantly reduce the overall performance of an EA.

Every developer has a choice!

That's not true. Analyzing the history does not decrease the performance of the EA. Instead of your long CheckOrder(), it is enough to write something like this (real working code):

///
/// Отслеживает поступление новых трейдов в истории трейдов.
///
void TrackingHistoryDeals()
{
    int total = HistoryDealsTotal();
    //Перебираем все доступные трейды и формируем на их основе прототипы будущих позиций типа COrder
    for(; dealsCountNow < HistoryDealsTotal(); dealsCountNow++)
    {  
        ulong ticket = HistoryDealGetTicket(dealsCountNow);
        AddNewDeal(ticket);
        graphRebuild = true;
    }
}

That's all. The arrival of new trades will be automatically detected by the TrackingHistoryDeals() function, which in turn will be called by the system timer. This function must also be called in OnTradeTransaction(), for example at occurrence of TRADE_TRANSACTION_DEAL_ADD event, in order to gain speed and not to depend on the set timer permission. If this event is lost, the Expert Advisor finds out about the changes a bit later (in my case it is 200 ms), waits for the next call of the timer and gets information about the order triggering.

 
C-4:

Looked at your code more closely. You are complicating things. There should not be any "crash" mode. Regardless of whether you use synchronous or asynchronous type of trading, you should focus on analyzing the trading environment. The analysis of events such as OnTradeTransaction is of an auxiliary nature.

This is not true. The analysis of the history does not reduce the performance of the Expert Advisor. Instead of your long CheckOrder(), you only need to write something like this (real working code):

That's all. The arrival of new trades will be automatically detected by the TrackingHistoryDeals() function, which in turn will be called by the system timer. This function must also be called in OnTradeTransaction(), for example at occurrence of TRADE_TRANSACTION_DEAL_ADD event, in order to gain speed and not to depend on the set timer permission. If the event is lost, the Expert Advisor finds out about the changes a bit later (in my case it is 200 ms), waits for the next call of the timer and gets information about the order triggering.

We are speaking different languages.

You hold your opinion, and I, if you allow me, will hold mine.

You don't even see the obvious things:

When the TradeTransaction event arrives, you don't need to check ANYTHING - ALL the data already exists!

The CheckOrder() function does NOT work at all if the TradeTransaction event has arrived!!!

 
Mikalas:

We are speaking in "different languages".

Stay with your opinion, and I, with your permission, will stay with mine.

No, we are speaking the same language - MQL5 and its asynchronous dialect OrderSendAsync. No matter how you look at it, the tasks in Async need to be solved in the same way. Take a look at myarticle above. Asynchronous code - synchronously interacting with external experts. Essentially a non-trivial manifestation of polymorphism. All thanks to the fact that the emphasis in this code is placed on analysis of changes of the trading environment. This proves once again that the event model is useful but of secondary character, which we can do without even in asynchronous operations.
 
C-4:
No, we are speaking the same language - MQL5 and its asynchronous dialect OrderSendAsync. No matter how you look at it, you have to solve the same problems with Async. Take a look at myarticle above. Asynchronous code - synchronously interacting with external experts. Essentially a non-trivial manifestation of polymorphism. All thanks to the fact that the emphasis in this code is placed on analysis of changes of the trading environment. This proves once again that event-driven model is useful, but of secondary importance, and we can do without it even in asynchronous operations.
Vasiliy, don't be stubborn, run the example on demo - then you will understand EVERYTHING!
 
Mikalas:
Vasily, do not persist, and run the example on a demo - then you will understand EVERYTHING!

Thanks, don't feel like it any more:

2015.02.05 23:37:21.147 TestTradeTrans (AUDCAD,H1) OnTradeTransaction: Order ticket not received. Request = 14

2015.02.05 23:37:20.767 TestTradeTrans (AUDCAD,H1) OnTradeTransaction: Order ticket not received. Request = 13

2015.02.05 23:37:20.464 TestTradeTrans (AUDCAD,H1) OnTradeTransaction: Order ticket not received. Request = 12

2015.02.05 23:37:20.105 TestTradeTrans (AUDCAD,H1) OnTradeTransaction: Order ticket not received. Request = 11

2015.02.05 23:37:19.912 TestTradeTrans (AUDCAD,H1) OnTradeTransaction: Order ticket not received. Request = 10

2015.02.05 23:37:19.832 TestTradeTrans (AUDCAD,H1) OnTradeTransaction: Order ticket not received. Request = 9

2015.02.05 23:37:19.036 TestTradeTrans (AUDCAD,H1) OnTradeTransaction: Order ticket not received. Request = 7

2015.02.05 23:37:05.723 TestTradeTrans (AUDCAD,H1) OnTradeTransaction: Order ticket not received. Request = 6

2015.02.05 23:36:59.919 TestTradeTrans (AUDCAD,H1) OnTradeTransaction: Order ticket not received. Request = 5

2015.02.05 23:36:59.199 TestTradeTrans (AUDCAD,H1) OnTradeTransaction: Order ticket not received. Request = 4

2015.02.05 23:36:53.693 TestTradeTrans (AUDCAD,H1) OnTradeTransaction: Order ticket not received. Request = 3

2015.02.05 23:36:52.689 TestTradeTrans (AUDCAD,H1) OnTradeTransaction: Order ticket not received. Request = 2

2015.02.05 23:36:44.410 Experts AutoTrading is enabled

2015.02.05 23:36:41.995 TestTradeTrans (AUDCAD,H1) Order not sent! AUDCAD Return Code = AutoTrading is not allowed by the client terminal

2015.02.05 23:36:39.996 TestTradeTrans (AUDCAD,H1) Order not sent! AUDCAD Return Code = AutoTradeTrans is not allowed by the client terminal

2015.02.05 23:36:39.958 TestTradeTrans (AUDCAD,H1) Order not sent! AUDCAD Return Code = AutoTradeTrans is not allowed by the client terminal

2015.02.05 23:36:34.581 MQL5 'TestTradeTrans.mq5' successfully compiled

I've managed to disable it, otherwise it would have flooded the entire terminal.

Z.I. By the way, do not try to embed this code into the article. This example is not acceptable under any circumstances, because it spams horribly with uncountable orders on every tick!!!

 
C-4:

Thanks, I don't feel like it any more:

I managed to turn it off, otherwise the bounces would have flooded the whole terminal.

:)

1. EXAMPLE for FORTS

2. Can't you put brackpoints?

3. I get the impression that you're reading messages through a line :)

Let's do it this way.

I'll ask you questions and you answer them, OK?

Question 1: How do you recognize the Order Ticket (by sending OrderSendAsync command) if no TradeTransaction event has arrived (or is not used)?

1234567
New comment
Reason: