Question about the OnTradeTransaction function - page 4

 
Mikalas:

That's because the exchange has no kitchen (only commissions) and FOREX has millions of MMM followers,

there may be $100, but EVERYONE has it! Huge money, there is something to count! :)

I don't understand MetaQuotes )

For forex kitchens there is a great MT4 terminal.

Many forex kitchens never provide access via MT5, they don't need it for fuck's sake.

Is it impossible for so many years to make a terminal close to the exchanges?

If they have a good terminal, they will have a lot of clients who want to provide MT5 services.

 
Serj_Che:

I don't understand MetaQuotes )

For forex kitchens there is a great MT4 terminal.

Many forex kitchens never provide access via MT5, they don't need it for fuck's sake.

Is it impossible for so many years to make a terminal close to the exchanges?

If we have a good terminal, there will be a lot of clients who want to provide MT5 services.

It's not about MQ, it's about brokers.

Brokers benefit from clients making trades - more trades - more commission.

The robot will only make "correct trades", and by placing orders "by hand" people are very

The robot will only make "correct" deals and by placing a hand order people make mistakes very often (I have made this mistake many times myself),

You get caught, you swear, you close the order with a loss, you want to get it back, you have set it wrong again, etc.

And the broker and the exchange got a commission :)

So for the exchange and especially for the broker QUIK is the motherland.

 
Mikalas:

Vasily, is there going to be an answer?

I don't think so.

Did I win?

I'll give you an answer tonight. I can't right now.
 
C-4:

Don't complicate things. It is not necessary to use asynchrony to trade on FORTS. For a start, take a look at 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 doesn't prevent it from working in synchronous mode without getting all sorts of OnTradeTransaction and other events.

The solution must be based on your task. In MetaTrader 5, you have only one active position at any given time, and that is what you need to monitor. There is no need to look into the order history. If you still need the order history, you should clarify your objective.

No, Vasily, you have not quite understood my aim. I'm not going to write anything or trade on FORTS, I've just begun to learn mql5. I started to read this article earlier. But I've read no more than 2 pages and gave up. I don't think I need it, I'm a NT myself. But a clear explanation of OrderSend and OrderSendAsync difference is useful. That's pretty much what I expected.

If we skip the asynchronous order submission and use OnTradeTransaction to track what is happening in the account, wouldn't this improve the EA's performance?

It is one thing to perform a check on every tick, and it is quite another thing to check only if there was some change in the account. Am I wrong? The pending order was activated, we have information about it. A position is closed, we can analyze the result of its closing. There are only a few checks during the time from opening to closing of a position. And in contrast, there are checks on every tick...

Here's another question: To determine the profit of a position, there is the PositionGetDouble(POSITION_PROFIT) function,but to determine the profit of a closed position, only OrderCalcProfit() has a heap of parameters that must be first obtained from this trade. Or maybe I'm so new to mql5 that I can't find a proper solution?

If you don't mind...

 
AlexeyVik:

No, Vasily, you've misunderstood my aim. I'm not going to write anything or trade on FORTS yet, I just started to learn mql5. I started reading this article earlier. But I've read no more than 2 pages and gave up. I don't think I need it, I'm a NT myself. But a clear explanation of OrderSend and OrderSendAsync difference is useful. That's pretty much what I expected.

If we discard asynchronous order submission and still use OnTradeTransaction to track what is happening in the account, won't it improve EA performance?

It is one thing to perform a check on every tick, and it is quite another thing to check only if there is some change in the account. Am I wrong? The pending order was activated, we have information about it. A position is closed, we can analyze the result of its closing. There are only a few checks during the time from opening to closing of a position. And in contrast, there are checks on every tick...

Here's another question: To determine the profit of a position, there is the PositionGetDouble(POSITION_PROFIT) function,but to determine the profit of a closed position, only OrderCalcProfit() has a heap of parameters that must be first obtained from this trade. Or maybe I'm so new to mql5 that I can't find a proper solution?

If it's not too much trouble...

OrderCalcProfit will not help.

You have to calculate the average price of all orders (in) and the average price of all orders (out),

then the profit of a closed position can be calculated.

We will have to look through the history.

 
Mikalas:

OrderCalcProfit will not help.

You need to calculate the average price of all orders (in) and the average price of all orders (out),

Then we can calculate the profit of a closed position.

We will have to investigate the history.

In principle, I understand it (even though I do not yet understand how to do it), but in this case, only the last closed position is important to me. Apparently this is better suited for the case when the position was filled. But my task is different.

I decided to rewrite my mql5 owls with martin. It is in the market continuously and opens next trade towards the last position...

Oops... that's how useful it is to communicate on the forum. After all, if the position can only flip when the pending order is activated, or close at the take, then I don't care about the size of the profit or loss. Well, if the last knee will give a minus, then you won't need anything... It is enough to know the type of a closed position... And this can be written into global level variable in OnTradeTransaction handler in case of transaction type TRADE_TRANSACTION_DEAL_ADD and in case of transaction type TRADE_TRANSACTION_HISTORY_ADD or provided that PositionsTotal is zero, place the next first order of a series... I wrote this down for myself, so as not to forget it :)))



 
papaklass:

...That is, the logic of your algorithm should be based on the TRADING ENVIRONMENT CHANGE, and not on the processing of any functions or events.

3 The frequency of checking the trading environment (on the tick, on the bar, on the timer, etc.) must correspond to the logic of your TS. That is, how quickly the trading environment change should be processed? If the logic of your TS requires processing the change as quickly as possible, then you can't avoid checking it on every tick...

And if your EA is multi-currency?
 
papaklass:

1. The OrderSendAsync() function is used when several orders need to be sent ONE time, a kind of batch sending. With batch sending, if you wait for the server to respond to each order (using OrderSend() function), there will be a significant total time lag in sending the entire batch. During this time lag, the market can change significantly! To avoid this time lag, we have introduced the OrderSendAsync() function. You should clearly understand this.

If you don't need to send batch orders, then there's no sense in using the OrderSendAsync() function.

The most reliable way to determine if an order, order, etc. has been triggered, is to monitor your trading environment. - is tracking your trading environment, not the triggering of any function or event. A function or event can work, but that does not necessarily change your trading environment. Why? Because an error can simply occur during the execution of the function.

Thus, the logic of your algorithm must be based on the VARIABLE CHANGE, but not on the processing of any functions or events.

3. the frequency of checking the trading environment (on tick, on bar, by timer, etc.) must fit the logic of your TS. That is, how quickly the trading environment changes need to be processed? If the logic of your TS requires processing a change as quickly as possible, then you can't avoid checking it on every tick.

Alexander, thank you for your feedback.

I understand it only to understand that I don't need it so far. For now the OrderSend function is enough for me.

2. Yes, I agree that the most accurate state can only be determined by monitoring the entire environment at every tick. But having such an event handler to ignore it... Well, I'm just experimenting. I perfectly understand your desire to help me make it somehow more reliable, but my goal is different. I don't need this Expert Advisor urgently, and I'm not writing it to order.

3. Perhaps in the final version of the EA I will return to testing on every tick, but for now...

The question was whether we could trust the OnTradeTransaction event handler if the documentation warns us against it

Also, the transactions may get lost in delivery from the server to the terminal.

And in which cases it is better not to trust, and in which cases you need to back it up with something.

I am very grateful to everyone, Vasiliy, Michael and you Alexander. I will be very happy and thank you again if you share any more thoughts.

 
papaklass:

This is exactly the question that both Vasily and myself have answered.

Think about it, if work of OnTradeTransaction() function must be checked all the same, it may be better to check the trading environment right away rather than after OnTradeTransaction() has been processed. However, it is a matter of taste.

And in the next thread Renat promised to work with the function and maybe in the next builds we'll get an improvement of this function.

But still, we are focused on asynchronous placing of orders. In this case, we have no reason to lose one order out of hundreds of ones. And yet Michael says that in six months with an incredibly large number of orders he has not lost a single transaction. And what is the probability to lose a transaction if the order is placed using the OrderSend() function?

And if improvement is forthcoming, it's one more reason to be concerned about it. Or am I wrong again?

 
denkir:
А если советник мультивалютный?


papaklass:

It's not clear what you want me to say.

An argument against the event model...
Reason: