OrderSendAsync() function - page 7

 

Asynchrony without control = chaos.

Asynchrony control can only be performed in OnTrade().

There is a need to identify a particular request in OnTrade().

Thus we come to that OrderSendAsync() must return the number of the ticket received from the server (excluding the time-out situation). The ticket number is needed to uniquely identify the request from both the server and the client.

By unifying this mechanism, the OrderSend() function can also be redesigned - it should return the ticket number, or "-1" in case of failure to send the order to the server.

Then, in the program, implement a class with the list of generated tickets.

At each OnTrade() event, we understand:

1. whether this is our action, or, for example, the action of another instance of the Expert Advisor (mages will no longer be needed).

2. What kind of request we are getting a response to.

Документация по MQL5: Торговые функции / OrderSend
Документация по MQL5: Торговые функции / OrderSend
  • www.mql5.com
Торговые функции / OrderSend - Документация по MQL5
 
voix_kas:

Thus, the OrderSendAsync() should return the ticket number received from the server (excluding timeout situation). The ticket number is needed to uniquely identify the request from both server and client.

Hello. Do you know what async is?
 
TheXpert:
Hello. Do you even know what asynchrony is?
<<Forget synchronous asynchrony!>>
 
We are now discussing adding an OnTradeResult(MqlTradeResult&info) function, which will have exact details on server responses.
Документация по MQL5: Стандартные константы, перечисления и структуры / Структуры данных / Структура результата торгового запроса
Документация по MQL5: Стандартные константы, перечисления и структуры / Структуры данных / Структура результата торгового запроса
  • www.mql5.com
Стандартные константы, перечисления и структуры / Структуры данных / Структура результата торгового запроса - Документация по MQL5
 
Renat:
We are now discussing adding the OnTradeResult(MqlTradeResult&info) function which will have exact details of server responses.

In my opinion, it should look like this from the user side:

the user writes a class for working with pointers and attaches the class of trade signal processing to it.

When a signal(s) appears, new objects are created and a request(s) is sent to the server; accordingly, the object exists until the signal is executed.

OnTrade monitors fate and makes a decision (either/or) or sends a new request or destroys the object as it has worked its way through.

This scheme needs identification of which object to process in connection with this Trade event activation.

 
Urain:

In this scheme, you need to identify which object to process in connection with this Trade event activation.

What is the problem?
 
TheXpert:
What's the problem?

Are you kidding?

Trade is now faceless, you can't tell which object in the list should be handled as it comes in.

 
Urain:

Are you kidding me?

Not at all. By the way, it's not worth much to bother with OnTrade, because it won't come 100% of the time (it's about the same as error 1 in MT4)

I mean, you still have to take out insurance.

Isn't it better to "make it good"?

 
TheXpert:

Not at all. By the way, it is not worth much to bother with OnTrade, because it will not come 100% of the time (which is about the same as error 1 in MT4)

I mean, you still have to take out insurance.

Isn't it better to "make it good"?

Justify why Trade won't come in ~100% of the time?
 
Urain:
Justify why Trade won't come in ~100% of the time?
Because broken packets, dropped connections etc crap. Unreliable. Unreliable -- you have to bounce back.