Learning and writing together in MQL5 - page 18

New comment
 
Yedelkin:

Well, you get the point. I'm telling you meticulously, you can check: OrderSend() function returns a boolean value. In this case, if the request is successfully checked, the order ticket is written into variable of MqlResult structure. I call it "return of the order ticket function" for myself. Here is the link to the source:"When sending a request to buy using the OrderSend() function, you can immediately find out the ticket of the order that was created if the request is successfully checked.

And if you are going to digress from the topic on the moderator's initiative, you have a similar answer: there is no and will never be an MQL5 tutorial, so it's unclear, what tutorial you are looking through. ... Maybe, we can either discuss the substance of the discussion, or nothing at all? :)

Thanks for the reply about the 'ban', I got it.

Not quite a correct understanding of what will happen when receiving a response from the server.

OrderSend() really returns a boolean value, but it's not the most important thing - the main thing is the structure, which is filled in when receiving a response from the server.

Yes, we do write a ticket into the structure (not only orders, but also deals), but is it more important than the rest of the information in the structure?

Let's analyze the structure of the response. In my opinion, the picture is approximately as follows

struct MqlTradeResult
{
//Очень важная информация
uint     retcode;          // Код результата операции
//Важная информация (важна при успешном запросе)
ulong    deal;          // Тикет сделки, если она совершена
ulong    order;         // Тикет ордера, если он выставлен
//Малосущественная информация (важна при успешном запросе, а также в случае реквоты)
double   volume;        // Объем сделки, подтверждённый брокером
double   price;         // Цена в сделке, подтверждённая брокером
//Малосущественная информация (важна при реквоте)
double   bid;           // Текущая рыночная цена предложения (цены реквота)
double   ask;           // Текущая рыночная цена спроса (цены реквота)
//Не существенная информация
string   comment;       // Комментарий брокера к операции (по умолчанию заполняется расшифровкой)
};

PS

The correct name for a structure is MqlTradeResult and not MqlResult (although it doesn't matter much in my opinion).

If the request is correct and executed, then volume and price are important in case the server "had the right" to reduce data parameters of transaction and it may require a reaction of Expert Advisor on actions of the server.

 
sergeev:

Unfortunately, I still don't get it.

you need to have a "time" field in the return structure for some reason. use the time in the order that appears. This is enough to control a small history.

"When sending a buy request using the OrderSend() function, you can immediately know the ticket of the order which was created when the request was successfully checked. But at the same time, the order itself may not yet appear in the client terminal and an attempt to select it using the OrderSelect function will fail. It follows from the second sentence that it is not always possible to work with the order properties (order time), even if its ticket is known. Therefore "use the time in the order which has appeared" is not an ideal solution. Also, the order may "not open" at all. My approach would solve the "small history control problem" regardless of what happened to the order before it went into history.
 
Interesting:

The structure should be called MqlTradeResult , not MqlResult (although it doesn't really matter in my opinion).

I wrote 'from memory', in response to advice to study a textbook
Interesting:

Not exactly a correct understanding of what happens when you receive a response from the server.

OrderSend() returns indeed a boolean value, but it's not the most important thing. The main thing is the structure which is filled in by receiving a response from the server.

Yes, indeed, a ticket is written to the structure (not only orders, but also deals), but is it more important than the rest of the information in the structure?

Well, let's not argue who has a better understanding :) See my reply to Sergeev. And here I repeat: according to the logic of the strategy I need only the ticket and the time of acceptance of the order for production. What you have emphasised is neither. "Very important information", such as retcode, does not help at all to optimise history uploading, which is what I'm talking about in general.
 
Yedelkin:
"When sending a buy request using the OrderSend() function, we can immediately know the ticket of the order that was created when the request was successfully checked. But at the same time, the order itself may not yet appear in the client terminal and an attempt to select it using the OrderSelect function will fail. It follows from the second sentence that it is not always possible to work with the order properties (order time), even if its ticket is known. Therefore "using the time in the order which has appeared" is not an ideal solution. Also, the order might "not open" at all. My approach would solve the problem of controlling a small history regardless of what happened to the order before it went into history.

I don't know, if it's so important ask developers to make additions to MqlTradeResult structure (in the form of time for which a trade is executed or an order is set).

Although I do not understand why it is needed, I'd rather add parameters to OnTrade().


 
Interesting:

I don't know, if it is so important, ask developers to make additions in structure MqlTradeResult(as time of deal executed or order placed).

Well, that's what I was asking about from the beginning :) Was there a precedent, so to speak :)

Addition. If someone would ask this question half a year ago, we could hope for a relatively fast appearance of this feature, while waiting for the next year - it's easier to input a variable for date. Although it will not be completely accurate, but still.

Interesting:

Although I don't understand why it is necessary, I'd rather add parameters to OnTrade().

Personally I can't wait any longer for Trade structure/parameters to appear. I've been waiting for it for 9 months already. I'll have to make do with what I've got.

 
Yedelkin:
I wrote "from memory", in response to advice to study a textbook Well, let's not argue, who has a better understanding :) Look at my reply to Sergeev. And here I repeat: according to the logic of the strategy I only need a ticket and the time of taking the order to production. What you have emphasised is neither. "Very important information" such as retcode does not help to optimise history uploading at all, which is what I'm talking about in general.

1. OrderSend() and history uploading, and this is where you should elaborate (I can't understand what you're talking about, and I think we're out of grass).

2. Logically, if analysis is based only on the OrderSend() result, the sequence of actions is as follows

a) Check the retcode, we need to know what really happened;

b) If the result is successful, obtain the ticket, volume and price. If a requote, we obtain the new prices (and check if they satisfy us).

c) If the answer is satisfactory and we do not have errors, obtain a ticket and time. You can use the server time or try to pull it out of the history (for the approximate calculation at the moment, it is better to know the server time);

d) If we are not satisfied with the answer (or satisfied only partially) - do not match the volume or we have a requote, decide on the next steps.

PS

In short, no matter how you look at it, the retcode should be looked at.

 
Interesting:

I don't know what you're talking about, and I think we're out of weed).

Look at the discussion from the beginning. ...No one is denying the importance of retcode, but for simple solutions you can do without it.
 
Yedelkin:
Look at the discussion from the beginning. ...No one is denying the importance of retcode, but for simple solutions you can do without it.

How critical is this option for you?

c) If the answer is satisfactory and there are no errors, we get a ticket. You can use the current time;

 
sergeev:

How critical is this option to you?


This is the standard variant (which has its disadvantages mentioned above) + independent time saving. Since I don't need retcode check, there is only a question about time saving: either independently or aesthetically with MqlTradeResult. Actually, this is the reason for the question :)
 
Yedelkin:
This is the standard option (which has its disadvantages, mentioned above) + self saving time. Since I don't need retcode check, there is only question about time saving: either by itself, or aesthetically with MqlTradeResult. Actually, this is the reason for my question :)

If the request is successful, sooner or later the trade will be in the history and the order will appear in the list. Consequently, you will be able to find out exactly what happened and how it happened.

And the suggested variant is so to say "at short notice", for those who want to get all the necessary data at once and not to bother with unnecessary actions.

Of course maybe add something else in the response server, but there are a number of features and reasons why the developers may not agree with this option (and the request, sorry little justified and confirmed by convincing arguments).

PS

Although, maybe I've missed something and the developers have decided it is quite reasonable.

1...111213141516171819202122232425...46
New comment
Reason: