OrderSendAsync() function - page 6
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
The point is that asynchronous request practically does not give any status "successfully sent".
Successful completion of the function only means "from client's point of view the order looks correct and was thrown into the network pipe, wait for response in OnTrade".
Sorry, been away for a bit.
However, I would like to clarify this phrase: "Wait for reply onTrade" which refers to a situation where a request did not reach the server.
If the request hasn't reached the server, no Trade event will be generated that could be related to this "missing" request. Right? And if so, I won't get any appropriate response in OnTrade() either. Would it be correct to draw such a conclusion:
If the OrderSendAsync() function finishes successfully, the request may fail to reach the server, and in this case it is useless to wait for the reply in OnTrade()
?
sergeev:
Sps! It turns out that a successfully sent asynchronous request can easily get lost and not get into the history.
No.
Explain, please. "No" is my conclusion incorrect, or is it a confirmation of it?
Most likely, it's an incorrect conclusion, but Renat said earlier that "if the request didn't reach the server, it has no chance to appear in the client terminal". If we continue with this logic: if the request has no chance to appear in the client terminal, it has no chance to get into the base terminal and therefore no chance to get into the base of historical orders. If this reasoning is not correct, where is the error and what is it?
The point is that asynchronous request practically doesn't give any status "successfully sent".
Successful completion of the function only means that "from the client's point of view, the order looks correct and was thrown into the network pipe, wait for the answer in OnTrade".
I hope that in the near future OnTrade will be improved in such a way that the"request did not reach the server" check can be organized by the user without any problems and, in fact, as well as other types of execution control.
because in its current form OnTrade is not capable of such feats, as it has no idea what kind of response it is working on.
I hope that OnTrade will be finalized in the near future so that the"request has not reached the server" check can be organized by the user without any problems, as well as other types of execution control.
because OnTrade as it stands now is incapable of such feats, as it has no idea what kind of response it is working on.
In principle, we can add a virtual response "request failed by timeout" if after sending a request we have not received a response from the server within 5-10 seconds that the request has reached the server.
This will allow us to catch a bounced request in OnTrade. But to do this, we will have to overload the function with parameters added.
If the request hasn't reached the server, no Trade event will be generated that could relate to this "missing" request. Right?
Yes, that makes sense.
We can add a virtual response as I described above. This will allow us to control the execution of asynchronous operations.
In principle, we can add a virtual "request failed by timeout" response if, after sending the request, we do not receive a response from the server within 5-10 seconds that the request has reached the server.
This will allow you to catch the bounce of an order in OnTrade. But to do that you will need to overload the function with parameters added.
You are scaring me,
People are waiting for improvement of OnTrade with parameters to implement control of execution. You have sounded that will be "in one build" i.e. chronologically in the next.
I've had three orders hanging around for months, waiting for a timeout, and you say "we can... "but we need to overload..."
You're not doing a refinement of OnTrade?
I don't know about others, but I'm not happy with the current situation. I put off writing all codes until MQL5 will have a functional that guarantees direct execution control, not indirect.
You're scaring me,
People are waiting for fine-tuning OnTrade with parameters to implement runtime control. You said that it will be "in one build" i.e. chronologically in the next build.
I've had three orders pending for months and you say "we can... "but we need to overload..."
you're not doing a refinement of OnTrade???
We'll try and do it in the next build.
There are actually a lot of tasks in the works, plus it's the summer holiday time - it's hard to maintain the usual pace of development.
Let's get hard and try to do it in the next build.
Tasks in the work is really a lot, plus it's still time for holiday - in the summer, the usual pace of development is difficult to maintain.
Phew, that's relieved :)
really scared, because quite a real situation, talked to each other and forgot, and people are waiting hopefully :)
I wish I could live long enough :))
The methaquotes make a strong, light and versatile terminal.
Strong and light they have already learned how to make. But there is another task here - continuity. We need to link in one terminal all the "chokepoints" of different trading platforms and a bunch of brokers. I think this is the problem. There is no more universal MQ5.
PS Yes OnTrade parameters are waiting. And on our stock brokers. And we need a successful way to handle asynchrony. Then there seems to be no competitors (for terminals). The tester alone is worth a lot...
In principle, we can add a virtual "request failed by timeout" response if, after sending the request, we do not receive a response from the server within 5-10 seconds that the request has reached the server.
It will allow us to catch a request breakage in OnTrade. But for this we will need to overload the function with parameters added.
We can add a virtual response as I described above. This will allow us to control the execution of asynchronous operations.